Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiş ve ilk dört maddeyi ele almıştık. Şimdi de beşinci maddeyi ele alalım:

Aralarında benzerlik ilişkisi olan nesneleri modellemek için kalıtım kullanmamak. (No inheritance hierarchy to model is-a relationships between the objects.)

Sebebi basit: Eğer kalıtım hiyerarşileriniz yoksa aynı tipten olan nesneleri ifade ederken pek de nesne-merkezli bir yöntem kullanmıyorsunuz demektir. Kalıtım kullanmazsanız polymorphismden faydalanamazsınız. Dolayısıyla kalıtım ve bunun sonucu olan polymorphism kullanılmıyorsa “neden nesne-merkezli bir dil kullanıyorsunuz?” sorusuna muhatap olursunuz? Hakikatten kalıtım ve polymorphism yok ise nesne-merkezli dilin en temel özelliklerinden sadece sarmalama ya da encapsulationu kullanıp sınıflar oluşturuyorsunuz demektir. Bu da Java’yı tam gücüyle kullanmamak, Java’yı C gibi kullanmak demektir.

Peki, kalıtım kullanılmadığında aralarında benzerlik ilişkisi olan yapıları nasıl ifade ederiz? Aşağıdaki basit sınıf bu durumu gösteriyor:

public class User{

	private String username; 
	private String password;
        private String name;
	private String lastname;
	private int type;

	public void register(){
		if(type == 1){
			doThis();
		}
		else if(type == 2){
		        doThat();
		}
		…
	}
}

Yukarıdaki örnekte User sınıfının farklı alt tipleri kalıtım yoluyla yeni sınıflar oluşturarak değil de aynı sınıf üzerinde oluşturulmuş int tipinde type isimli bir değişkenle temsil ediliyor. Bunun en temel problemi, farklı tiplerin davranışlarını farklılaştırmak için metotlarda bol miktarda “if/switch” cümleleri kullanmak zorunda kalmaktır. Eğer kalıtım kullanılsaydı “if/switch” cümlelerini kullanmaya gerek kalmayacaktı çünkü register() metodunun farklı, override eden implementationları olacaktı.

Yukarıdaki durumda User sınıfının ve register() metodunun abstract olduğunu, dolayısıyla da onu extend eden sınıfların register() metodunu override ettiğini düşünebiliriz.

public abstract class User{

	protected String username; 
	…

	public abstract void register();
}

--------------------------------------------------------------
public class IndividualUser extends User{

	…

	public void register(){
		doThis();
	}
}

--------------------------------------------------------------
public class CorporateUser extends User{

	…

	public void register(){
		doThat();
	}
}

Yukarıdaki koddan da görüldüğü gibi bir kalıtım hiyerarşisi ve override edilmiş metotlar ile hem nesne açısından daha hoş bir yapıya ulaştık hem de “if/switch” cümlelerinden kurtulduk. Bu sayede tipe göre davranışı ayırt etmek artık JVM’in görevi haline geldi.

Öte taraftan kalıtım kullanmanın sarmalamaya (encapsulation) ters bir yapı olduğunu ve hiyerarşideki nesneler arasında ciddi bir bağımlılık (coupling) oluşturduğunu da söylemeliyiz. Örneğin User sınıfında yapılacak bir değişiklik alt sınıfları etkileyecek ve onların değişmesini gerektirebilecektir. Bu durum “inheritance violates encapsulation” yani “kalıtım sarmalamayı bozar” olarak ifade edilir. Bu sıkıntıdan dolayı kalıtım kullanırken dikkatli olmakta fayda vardır. Bu konu aslında burada hızlıca geçiştirilecek kadar basit değildir. Bir başka yazıda bunu ele alabiliriz.

Bol kalıtımlı günler dilerim.

Toplam görüntülenme sayısı: 1153

Geliştirdiğimiz Java kodunun nesne-merkezli olmadığının 10 işaretinin neler olduğunu bu yazıda listelemiş ve ilk üç maddeyi ele almıştık. Şimdi de dördüncü maddeyi ele alalım:

Kodunuzda hiç ya da çok az sayıda arayüz olması. (No or very few interfaces in the code.)

Bu maddede ne demek istediğimi hiç lafı dolandırmadan söyleyeyim: Ben Java ile geliştirilmiş bir projeye bakıp da o projede arayüz (interface) göremezsem, ya da olsa bile projenin örneğin DAO nesneleri gibi iş mantığını içermeyen kısımlarındaysa, o projede herhangi bir tasarım faaliyetinin yapılmadığına karar veririm. Çünkü arayüz kullanmadan karmaşılığı ve değişimi yönetebilmek mümkün değildir.

Kamaşık yapıları anlaşılır hale getirmenin en temel yöntemi, bölüp parçalamak ya da daha teknik ifadeyle soyutlamaktır (abstraction). Bölüp parçalayarak yeni soyutlamalar yapmak, zihnimizin en temel anlama ve problem çözme mekanizmasıdır. Yazılım geliştiriken bölüp parçalamanın sebebi ise temelde sorumlulukları ayırmaktır ki bunu da kadim “separation of concerns” yani “ilgi alanlarının ayrılması” prensibi ile açıklıyoruz.

Nesne merkezli teoride öncelikle üzerine eğilinecek, soyutlanacak, ayrılacak ilgi alanı, sorumluluklardır. Nesne-merkezli diller de önceliği daima sorumluluklara verir. Nasıl veri merkezli yaklaşım, verilerin sağlıklı bir şekilde modellenmesi, saklanması, sorgulanması gibi konuları önceliyor ve veriyi bu amaçlarla soyutluyorsa nesne-merkezli yaklaşım da önceligi sorumluluklara verip, her şeyi oradan başlatıyor. Burada ilgi alanlarını yani nesnelerin sorumluluklarını birbirinden ayırmak ve ilgili olanları bir araya toplamaktan bahsediyorsak, tabi olarak arayüzlerden yani interfacelerden bahsediyoruz demektir. Unutmayın, kodunuzda arayüz kullanmıyorsanız, muhtemelen veri merkezli ya da data-driven bir düşünce tarzına sahipsiniz demektir. Sonuçta yaptığınız da sorumluluklardan değil de veriden yola çıkarak yazılımınızı tasarlamanız ve geliştirmeniz demektir.

Öte taraftan değişimin en sıkıntılı tarafı, değişimin etkisinin yayılmasını önleyememektir. Değişimi maliyetli yapan çoğu defa kendisi değil, etkisini düzeltmenin maliyetinin yüksek oluşudur. Değişim ise çoğu kez, aynı sorumluluğu değişik şekillerde yerine getirme ihtiyacından doğar öyle ki sorumluluğun farklı şekillerde nerede ve nasıl yerine getirildiğini diğer nesneler bilmemelidirler ki değişimi kontrol altında tutabilelim (minimum info principle). Bir başka deyişle nesneler arasındaki bağımlılığı (coupling) arayüz seviyesinde tutmalıyız. Bu da tipik bir arayüz kullanımıdır.

Önce karmaşıklığı, arayüz kullanımıyla nasıl daha rahat yönetiriz onu görelim. Düşünün ki bir ERP yazılımı geliştiriyoruz ve ürettip sattığımız yiyecek olan ve olmayan ürünlerimiz var. Bu ürünleri fiyatları var ve benzer şekilde bu ürünler satılıp da müşterimize gönderilinceye kadar depolarımızda tutuluyorlar. Bu yapıyı şöyle modelleyebiliriz:

Görüldüğü gibi Cost ve Location, ürünün müşteriye olan maliyetini ve hangi adreste depolandığını gösteren sınıflardır. Food ve NonFood ise Product tipinden olup, satıldıkları için maliyetleri, depolandıkları için de depo adresleri olan alt sınıflardır. Peki bu ERP yapımızı bu şekilde kurguladık ve sattık. Daha sonra müşterilerimizin bazılarının danışmanlık ürünleri de olmaya başladı. Ne yapabiliriz? Muhtemelen Consultancy isimli bu yeni Product tipimizi ya NonFood‘un ya da doğrudan Product‘ın alt sınıfı yaparız. İlk hali denersek sınıf diyagramımız şöyle olur:

Consultancy tipi her halukarda bir Product‘tır dolayısıyla hem maliyeti hem de deposu vardır. Bu ise problemli bir durumdur. Çünkü en başta maliyeti olup da depolanmayan bir ürün düşünülmediğinden yani maliyet de depolanma da doğrudan Product olmaya bağlandığından Consultancy‘nin ifadesinde problem vardır. Çünkü Consultancy satılabilirdir ama depolanabilir değildir.

Bir başka durumu daha düşünelim: Bazı müşterilerimiz, eski kullandıkları bilgisayarları örneğin kurayla çalışanlarına dağıtıyor. Bu dağıtmayı da senede bir defa yapıyor. Ama müşteri bu sırada açığa çıkanları depoluyor ve sistemde bunların envanterini de tutmak istiyor. Yani elimizde satılmayan ama depolanan ürünler var ve bunun için Gift isimli yeni bir tipe ihtiyacımız var. Her iki sınıfın da problemi aslında sahip olmadıkları davranışı gösteriyor olmaları.

Genişçe düşünülmeden geliştirilen sistemlerde miras kullanımı genelde böyle problemlere yol açar. Yapılacak şey bu iki sınıfın yerine getirmediği davranışlar için sıradışı durum fırlatmasıdır. Hoş bir durum değil ama yapacak bir şey yok, çünkü değiştirmek çok pahalı. Peki nedir bu iki sınıfın durumunu sıkıntılı yapan şey? Aslında sıkıntı, tam bir tip problemidir. Yani Consultancy ve Gift, ürün olarak ifade edilmiş ama ilki satıldığı halde depolanmıyor, ikincisi depolandığı halde satılmıyor. Belli ki biz en başta Product‘ı tarif ederken hata yaptık. Product’ı, hem satılabilen hem de depolanabilen olarak tanımladık. Halbuki, depolanmadığı halde satılabilen, satılmadığı halde depolanabilen ürünlerin olabileceğini, dolayısıyla, ürün olmaklık ile satılabilmek ve depolanabilmenin ayrılması gerektiğini zamanında düşünmek gerekirdi. Bir şeyi o şey yapan ile o şeye eklemlenen farklı özellikleri ayırtedebilmek ancak arayüzler sayesinde olabilir. Bu anlamda bir tipin sınıfında onun asli özellikleri tanımlanmalı, arayüzünde ise devraldığı yetkinlikleri tanımlanmalıdır. Çünkü, yetkinlikler, bir şeyin en temel, ona has ve ayırt edici olan özelliklerinden değilse, muhtemelen sınıfta tanımlanmamalıdır, paylaşiıabilecek şekilde bir arayüzde tanımlanmalıdır. Bu anlamda sınıfın içine koyduklarınıza dikkat edin. Çünkü hiç bir interface yaratmadan sadece sınıftan devralarak ilerlerseniz, böyle durumlarla karşilaşmanız işten bile değildir. Aynı yapıyı arayüz tabanlı olarak şöyle tasarlamış olsaydık:

Yukarıdaki tasarımda satılabilir olmak ile depolanabilir olmak sırasıyla Sellable ve Storable arayüzleriyle ifade edilmiştir. Bu durumda Consultancy hem bir Product hem de Sellable tipi olurken, Gift de benzer şekilde hem bir Product hem de Storable‘dır.

Arayüz kullanmak her şeyden önce bir tasarım faaliyetidir; tasarım arayüzlerle başlar. Arayüzler, nihayetinde nesneleri oluşturulamadığından, tabiri caizse kodun değil de tasarımın parçasıdırlar. Arayüzleri kullandıkça daha kaliteli yazılımlar geliştireceksiniz.

Bol arayüzlü günler dilerim.

Toplam görüntülenme sayısı: 1304