Merhaba arkadaşlar,
Tasarım prensiblerini anlattığımız en son yazımızda Open - Closed prensibini incelemiştik. Bugünkü yazımızda Liskov Substitution prensibini incelemeye çalışacağız.
Liskov Substitution prensibini fikir sahibi Barbara Liskov isimli bir hanım efendidir.
Kendisi hakkında bilgi vermek gerekirse; "Barbara Liskov 2002 yılındaki 29 sayfalık özgeçmişinde araştırma alanlarını işletim sistemleri, dağıtık programlama, programlama dilleri ve programlama metodolojisi olarak belirtmiş. Halen MIT'de çalışan olan Liskov, Amerika'da bilgisayar bilimleri alanında doktora derecesi alan ilk kadındır. Venüs işletim sistemi, CLU programlama dili, nesne tabanlı programlama Liskov'un 1970'lerden beri çalışmalarının ürünlerindendir. Liskov, 2004 yılında John von Neumann madalyası ve 2008 yılında Turing ödülünü almıştır." görüldüğü üzere kendini aşmış bayan mühendis arkadaşlarımıza örnek olacak birisidir.
Konumuza dönersek Barbara abla ne diyor ? Barbara abla uygulamalarımız da kullandığımız üst sınıf ve alt sınıflar için birbiriyle uyumlu olmalıdır. Üst sınıfta olupta, alt sınıfın kullanamayacağı bir alan, özellik, method vs. olmamalıdır. Eğer böyle bir durum olursa üst sınıfta tip kontrolü yapmamız gereken durumlar olabilir. Bu da zaten Open - Closed prensibine ters düşer. LSP'ye ters düşen bir implementasyon OCP'ye de ters düşer.
Her zamanki gibi konunun daha iyi anlaşılması için basit bir örnek yapalım. 2 adet kalemimiz olsun. Birisi normal kurşun kalem, diğeri dolmakalem. Bunların nesneleştirirsek herkesin aklına aşağıdaki gibi bir resim çıkacağını düşünüyorum.
Kalem sınıfından türeyen iki adet sınıfımız bulunmaktadır. Buraya kadar herşey çok güzel. İmplementasyon aşamasında KursunKalem ve DolmaKalem nesneleri Kalem gibi davranış gösterebilir.
Bir adet sınıf daha bu hiyerarşiye ekleyelim. Kalemimiz MarkerKalem olsun. MarkerKalem ve DolmaKalem'ler bittikleri zaman tekrar doldurulabilir kalemlerdir(Artık markerlarda doldurulmuyor ya neyse. Bizim çocukluğumuz da dolduruyorduk hey gidi günler :)).
O zaman ben boya doldur işlemini nereye koymalıyım? İki alt sınıfta bu işlemi yapıyorsa bu işlemi üst sınıf olan Kalem sınıfına mı koymalıyım?
Yukarıdaki uml aslında işimizi gayet iyi görür. BoyaDoldur methodunu virtual yapar. KursunKalem sınıfında override ederken metodun içini boş bırakır veya notimplementedexception fırlatırım. Diğer kalem türlerinde yapmak istediğim ne ise onu yaparım.
İşte Barbara abla burada bize kızıyor madem alt sınıfın üst sınıfın yerine geçemiyor. O zaman alt sınıfı ya oradan çıkar ya da adam gibi bir ara sınıf koy.
Barbara ablamın ilk dediğini yapabiliriz ama bu bizim kalem özelliklerini tekrar tanımlamımıza neden olur. İkinci dediği daha mantıklı gözüküyor. Ara sınıf getirerek BoyaDoldur işlemini bu sınıfa verebiliriz.
Şu şekilde olabilir mi?
Sanki oldu gibi. Artık KursunKalem,MarkerKalem,DolmaKalem nesneleri Kalem nesnesi gibi davranabilir. Bu çözümü ara sınıf koymak yerine bir interface tanımlayıp DolanKalemlere uygulatılabilir.
İşte bu şekilde yapınca Barbara abla bize mutlu bir tebessüm gönderiyor afferim cahil çocuklarıma diyor:)
Konuyu parmaklarımızın yazdığı kadar anlatmaya çalıştık arkadaşlar. Bir sonraki yazımızda görüşmek üzere :)
Gerçekten güzel bir yazı olmuş. Bu arada biraz geç olsa da hayırlı olsun diyim :) Güzel blog, güzel yazılar, inş. böyle devam eder.
YanıtlaSilNot: bebekle birlikte doktora yapmaya çalıştığım şu zorlu zamanlarda Barbara hanımın hikayesi de iyi geldi ;)
Güzel dileklerin için teşekkür ederim. Bugün söylediğim bir cümle aklıma geldi. Bir insanın en büyük moral bozucusu ve en büyük moral vericisi kendisidir. Bir işi yapabileceğimize inanmadıktan sonra o işi yapmamız imkansızdır. Başarılı Olacağına inanıyorum inş.
YanıtlaSil