Ana içeriğe atla

Nesne Yönelimli Programlama(Object Oriented Programming) - 2

Bir önceki makalemizde nesne yönelimli programlama'da Encapsulation ve Classification konularını incelemiştik.


Bu makalemizde aşağıdaki konulara değineceğiz.
·         Inheritance
·         Polymorphism
·         Abstraction

INHERITANCE

Nedir bu miras almak yada kalıtım almak?

Biyolojiden de bildiğimiz üzere ailemizden bazı özelliklerimizi kalıtım alırız.Örneğin; babanızda mavi göz geni varsa sizin ve sizden sonraki çocukların mavi gözlü olma durumu vardır.Yani o geni taşıyabilirsiniz.Ama sizden önceki jenerasyonda hiç mavi göz geni yoksa siz ve sizden sonraki çocuklarda da bu genin olma olasılığı yoktur.
Kısacası OOP'deki inheritance özelliğide aynı bu duruma benzer.Inheritance kullanırken dikkat etmemiz gereken durum, bir nesne ancak bir nesneden miras alabilir.Miras alma durumunun en genel ve anlaşılır örneklerinden biri ise “Bir çocuğun sadece bir biyolojik babası olabilir ancak bir babanın birden fazla çocuğu olabilir.”
Şimdi kodumuzla örnekleyelim;
public class Aksesuar
 {
        public string UrunAdi { get; set;}
        public decimal UrunFiyati{ get;set;}
        public DateTime UretimTarihi{get;set;}
        public string Bilgi()
        {
            return string.Format("Bu ürünün üretim tarihi:{0}", this.UretimTarihi);
        }
 }

Burada bir Aksesuar nesnesi mevcut.Şimdi bir kitap ayracı nesnesi yapacağım.Kitap ayracı nesnesinin de; adı, fiyatı, üretimTarihi gibi özellikleri bulunur.Fakat bunun yanında bir de tip gibi bir özelliği olduğunu düşünelim.Dolayısıyla kitap ayracı aynı zamanda bir Aksesuar oldu. İşte nasıl miras aldığımızın bir örneği.
public class KitapAyraci:Aksesuar
{
  public string Tip { get; set; }
}
Şimdi arayüz kısmında KitapAyraci nesnesini kullanalım.Aşağıdaki örnekde olduğu üzere kitap ayracı nesnesi içine UrunAdi,UrunFiyati,UretimTarihi özellikleri de geldi.Ayrıca Tip özelliğide, sadece KitapAyraci nesnesine eklenmiştir.


POLYMORPHISM

Polymorphism çok biçimlilik anlamına gelmektedir.Aslında bunu çok sevdiğim tiyatro oyuncusu Genco Erkal ile örneklendirmek istiyorum.Hiç oyununu izledinizmi bilmiyorum ama ben hiç bir oyununu kaçırmam.Neyse olayımız  Genco Erkal’ın birden fazla tiyatro oyununda oynamakta olması ve her oyununda farklı karakterleri canlandırmasıdır.Yani oynadığı rol değişmektedir.Fakat o oyunun oyuncuları kısmında rolü ne olursa olsun kendi adı yazmaktadır.İşte çok biçimlilik budur.
OOP’de bir nesnedeki method yada property virtual olarak tanımlanarak miras verdiği diğer sınıflar içinde farklı davranışlar sergileyebilmektedir.
Aşağıdaki örneğimizde bir araç nesnesi bulunmaktadır.Bu nesne içinde VitesBilgisi methodu virtual tanımlanmıştır.Çünkü bu sınıftan türeteceğim diğer nesnelerin VitesBilgisi farklı olabilir.Default olarak 4 vites diyoruz.Eğer değilse o nesne içinde bu methodu eziyoruz.Yani yapacağı işi biçimlendiriyoruz.
public class Arac
 {
       public int TekerlekSayisi { get; set; }
       public string Marka { get; set; }

       //Burdaki method virtual tanımlandı.Bunun sebebi bu sınıftan miras alan sınıflarda       //bu methodun döndürebileceği değer o sınıflar içinde değişebilir.
       //Virtual sınıflar miras alınan sınıflarda ezilebilir olurlar.Yani methodun
       //yapacağı işler değişir.
       public virtual string VitesBilgisi()
       {
           return "Bu araçta 4 vites mevcuttur.";
       }
 }

Şimdi bu nesneden miras alan iki nesne yaratalım ve VitesBilgisi methodu için polymorphism uygulayalım.
public class Bisiklet:Arac
{
        public string KullaniciTipi { get; set; }
        public override string VitesBilgisi()
        {
            return "Bisiklet 16 vitestir.";
        }
}

Buradaki Bisiklet nesnesi Arac nesnesinden miras almıştır.Arac nesnesi içindeki VitesBilgisi methodu ezilerek geriye “Bisiklet 16 vitestir” mesajını döndürmektedir.Araba nesnesi için ise VitesBilgisi methodu “Bu araçta 4 vites mevcuttur.” mesajını döndürür.Yani bu method Araba sınıfında ezilmemiştir ve default olarak yapması gereken işi yapar.
public class Araba:Arac
 {
        public Color Renk { get; set; }
        public int KapiSayisi { get; set; }
        public bool HidrolikDireksiyon { get; set; }
 }

ABSTRACTION

Inheritance kullanırken uygulanabilecek bir yaklaşımdır.Abstraction uygulanacak sınıflara, instance alma işlemi uygulanamaz.Bu sınıflar sadece miras vermek için kullanılır.OOP’ye başlarken dünya üzerindeki her nesneyi düşünmek gerek demiştik.Malzeme de bir nesne olmasıyla birlikte soyut bir kavramdır aslında.”Neyin malzemesi?” diye düşünürüz kullanıldığı zaman.Malzeme denildiğinde aslında yemek yapmak için kullanılan malzemeler, mobilya yapmak için kullanılan malzemeler ve benzeri malzemeler akla gelmektedir.Yani malzeme tek başına çokta birşey ifade etmez.İşte biz bu tür nesneleri soyutlayarak kullanırız.Yani program içinde türetilebilir olmamaları için abstraction uygulanır.

Abstract sınıfların bazı özellikleri;
  • Instance alınamazlar.
  • Abstract kelimesi ile işaretlenirler.
  • Abstract sınıflar içinde oluşturulan abstract method’ların ve property’lerin ne yapacağı o sınıf içinde yazılmaz.Method ve property içleri boştur.Ve kime miras veriyorlarsa abstract yaratılan methodlar ve property’ler implemente edilmek zorundadırlar.(Yani miras verilen sınıfta ne iş için kullanıldığı mutlaka yazılmak zorundadır.)

Şimdi bu anlattıklarımızı örnekleyelim.İşletim sistemi nesnesi soyut bir kavramdır.”Hangi işletim sistemi?” sorusu aklımıza gelir.İşte Linux,Windows gibi nesnelerimizi işletim sistemi nesnesinden miras alarak kullanacağız.
 public abstract class IsletimSistemleri
 {
        protected abstract DateTime CikisTarihi { get; set; }
        public abstract string KarsilamaMesaji();
        //propected:Sadece bu sınıftan miras alınan sınıflar erişebilir
        protected string _versiyonBilgisi;
        public string VersiyonBilgisi
        {
            get { return _versiyonBilgisi; }
            set { _versiyonBilgisi = value; }

        }
 }
CikisTarihi property’si ve KarsilamaMesaji methodu abstract olarak tanımlandı.Bu yapılar her, işletim sistemi için farklılık gösterebileceğinden bu şekilde tanımlıyoruz.Şimdi bir sınıfa bu sınıftan miras verelim. Aşağıda ki Abstraction kullanımına dair örneği inceleyebilirsiniz.
 public class Linux:IsletimSistemleri
 {
        private string _ad = "Linux";
        public string AD
        {
            get { return _ad; }
        }
        private DateTime _cikisTarihi;
        protected override DateTime CikisTarihi
        {
            get
            {
                return _cikisTarihi;
            }
            set
            {
                if (value > DateTime.Today)
                    throw new Exception("Çıkış tarihi bugünden büyük olamaz.");
                else
                    _cikisTarihi = value;
            }
        }
        public override string KarsilamaMesaji()
        {
            return "Linux'e hoşgeldiniz";
        }
 }
Bir de Windows nesnesi eklenmiş şekilde class diagramında bu nesneyi görelim. 

Pelin KARACAN

Yorumlar

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara