Bir önceki yazıda programcı ve developerdan bahsettik, konumuza devam edelim.

Architect ya da mimar, geliştirilecek olan yazılım sisteminin yüksek seviyeli tasarımını yapan kişidir. Mimar, yazılım bileşenleri ile temel özelliklerini, aralarındaki iş bölümünü ve iletişimi, katmanlar ve aralarındaki ilişkileri, kullanılacak teknolojileri, donanım altyapısı vb. sistem özelliklerini, performans, güvenilirlik (reliability) gibi fonksiyonel olmayan ihtiyaçları yerine getirecek şekilde belirler. Bu açıklamadan da anlaşılacağı gibi mimar, fonksiyonel yapıları, her türlü detayıyla tasarlayan kişi değildir. Bu anlamda yazılım mimarı, mimari olarak kritik olan fonksiyonel yapılar üzerinden hareket eder, sistemin yüksek seviyeli özelliklerini ve haritasını bu kritik fonksiyonel yapıları kullanarak belirler, detaylı fonksiyonel tasarıma girmez.

Böyle bir pozisyon, açıklamasından da anlaşılacağı gibi, öyle pat diye bir-iki senede elde edilecek tecrübe ile doldurulamaz. Kaldı ki sadece tecrübe ile de doldurulacak bir pozisyon değildir yazılım mimarlığı. Soyut ve sistem bazında düşünme becerileri çok önemlidir. Örneğin bileşenlerin API tasarımını yapmak, ön bellek kullanımı (caching) kurgulamak, transactional yapılara karar vermek, kullanılacak teknolojilerin mesela performans açısından en iyi kullanımları (best practices) belirlemek, alınan kararların UML gibi formal bir yolla dokümante etmek ve yaygınlaştırmak vs. bu anlamda mimarın yapması gereken işlerdendir. (İşin açıkcası kurumun ve projenin büyüklüğüne göre, veri, integrasyon, uygulama vb. konularda ayrı ayrı mimarlara ihtiyaç duyulabilir. Bu durumda kurumsal mimarinin (enterprise architecture) farklı vechelerinden bahsediyoruz demektir. Burada ele aldığımız daha çok uygulama ya da çözüm mimarıdır.) Yazılım mimarı, yüksek seviyeli bu gibi kararların alınmasında öncü durumdadır ama muhtemelen etrafındaki developerlarla çalışarak ilerler. Aldığı kararların tüm yazılım geliştirme takımı tarafından benimsenmesi ve sürekli bir şekilde uygulanması için takım ile iletişimini sürekli olarak korur. Bu anlamda yazılım mimarı bürokratik olarak yazılım geliştirme biriminde olmasa bile projede takımın bir parçası olur. Hatta benim gözlemlediğim, ülkemizdeki pek çok yazılım projesinde çalışan mimarlar, yazılım da gelişiren, kritik ve öneli bileşenlerin geliştirme sorumluluğunu üzerinde tutan kişilerdir.

Ülkemizde bildiği iki teknolojiyi bir araya getirip yazılım geliştiren herkes kendini mimar yerine koyuyor. Böyle bir algı, yazılım mimarisi kavramını sadece teknoloji seçimine indirgeme basitliğinin bir sonucudur. Yani örneğin Java EE teknolojilerinden hangilerinin kullanılacağına karar vermek, mesela web tarafında JSF, orta katmanda Spring, arkada, veri tabanı iletişiminde JPA kullanmaya karar vermeyi, yazılım mimarının tek yapacağı iş olarak görmenin sonucudur. Halbuki mimarlık programcılıktan farklıdır ve sadece zamanla elde edilecek bir sıfat da değildir. Sonuçta iyi mimarlar iyi programcılık geçmişine sahip kişilerdir ama her programcı hayatının ilerleyen zamanlarda otomatik olarak mimar olacak demek değildir. Bu anlamda malesef bu ülkede yazılım mimarlığı, programcılığın ya da developerlığın tabi bir uzantısı olarak görülüyor. Bu roller, pek çok ortak yönleri olsa ve birbirlerine çok yakın çalışsalar da sonuçta farklı yetki ve görevleri olan kişiler. Ben senelerce belli teknolojilerde uzmanlaşmış ama soyut düşünce yeteneklerini geliştirmeye ağirlık vermemiş, teknolojsini ve iş alanını çok iyi bilen kişilerle tanıştım ve çalıştım.

Yazılım projelerinde iyi-kötü bir mimari yapının kurgulanması ve tüm takım tarafından uygulanması, o yazılımın daha tutarlı, daha yeknesak, birlikteliğinin (cohesion) daha yüksek olmasını sağlar. Merkezi olarak alınmayan kararlar nihayetinde yazılım sisteminin aynı şeyi pek çok yerde tekrarlayan, bileşenleri arasında kaotik bir iletişime sahip hale getirir. Mimari kararların, farkında bile olmadan sadece developer/programcılar tarafından alındığı bir yerde sistemin sonunda değişemez, performans, scalability gibi açılardan çıkmaza girmiş hale gelmesi kaçınılmazdır.

“No Silver Bullet” isimli makalesinin sonunda F. Brooks, yazılımın asli zorluklarına çözümler ya da “silver bullet” (gümüş kurşun ya da daha anlamlı bir Türkçeyle ifade etmek istersek, sihirli değnek) önerirken “great designers” yani “mükemmel tasarımcılar”dan bahseder. Makalenin yazıldığı 1987 yılında tasarımcı, mimar vb. ayırımların henüz çok farkında değildik, bu yüzden bu ayırıma takılmadan Brooks’un “mükemmel yazılım mimarları”ndan bahsettiğini iddia edebiliriz. Yazılım geliştirmenin yaratıcılık gerektiren bir süreç olduğunu, dolayısıyla en iyi uygulamaları bilen kişilerin, doğru kavramsal modelleri ortaya koyabileceklerini ifade eder Brooks. Sonra da mükemmel mimarların, mükemmel yöneticiler gibi çok az bulunduğunu vurgular. Bu yüzden Brooks, kurumlara, bünyelerindeki “mükemmel tasarımcı” adaylarını erkenden bulup, onları yetiştirmelerini tavsiye eder.

Kariyerine yazılım mimari olarak devam etmek isteyen arkadaşların yazılım mimarisi kitaplarını okumaları, uygulama, veri, entegrasyon vb. konulardaki mimari yaklaşıkmları bilmeleri, farklı seviyelerde tasarım çalışmalarında bulunmaları, tasarım ve mimari kalıpları özümsemeleri, kullandıkları dilleri ve bu dillerdeki bileşen ve çerçeve (framework) yapılarını, bu teknolojilerin en iyi uygulamalarını iyice öğrenmeleri, performans, ölçeklenirlik gibi mimari konular üzerine çalışmaları ve soyut tasarım çalışmalarını ifade etmek için gerekli UML gibi formal yapıları ögrenmeleri gereklidir.

Kaliteli yazılımlar için kaliteli yazılım mimarlarına ihtiyacımız var.

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

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