Kalite#4 — Bileşenleri Kurgulamak (Component Principles)
Isınma yazılarından sonra artık biraz daha teknik konulara girmenin vakti geldi. Hepiniz Lego’yla oynamışsınızdır sanırım. Yani en azından çocukluğunuzda değilse bile çocuk olan bir ortamda elinize geçmiştir bu oyuncaklardan. Mesela ben 11 aylık kızıma hemen Lego aldım ve itiraf etmeliyim ki ondan daha çok oynuyorum:). Oynadıkça da bu oyuncak bileşenlerinin bazı özelliklerini farkettim. Asla bozulmuyorlar, kırılmıyorlar mesela. İstediğiniz kadar birleştirin sonra yeniden dağıtıp farklı bir şeyler yapın yine de bileşenler sapasağlam duruyor. Bileşenlerin bağlantı noktaları hep aynı şekilde tasarlanmış. Yerine geçme prensibine uygun bir şekilde hemen hepsi birbirinin yerine kullanılabiliyor. Basit ve zekice.
Aslında yazılım bileşenlerinden beklentilerimiz de aşağı yukarı aynı. Zekice tasarlanmış, basit ve sade bileşenlerden oluşması gerekiyor yazılımlarımızın da. Bileşen kavramını çok genel kullandığımın farkındayım. Yazımızın içeriğini daha fazla dağıtmamak adına şuraya tanımını yapalım:
Bileşen, sistemimizin yaygınlaştırılabilir en küçük birimidir.
Yani .Net dünyası için dll dosyaları buna bir örnektir. Veya Java için jar dosyaları, NodeJs için npm paketleri gibi.
Bileşenlerimizi oluştururken hangi sınıfın hangi bileşende olacağı bizim için önemli bir sorundur. Çünkü bileşenlerimiz arasındaki bağımlılıklar buna göre oluşacaktır. İşte bu noktada devreye bazı prensipler giriyor. Bu prensipleri orjinal adı ile kullanacağım. Türkçeleştirmeye çalıştığımda anlamı bozuluyor veya herkes kendisine göre türkçeleştirdiği için farklılıklar oluşuyor.
- REP: The Reuse/Release Equivalence Principle
- CCP: The Common Closure Principle
- CRP: The Common Reuse Principle
Bu prensiplerin amacı bizi bir bileşenin içeriği konusunda yönlendirmektir. Bileşenler arası ilişkiler konusundaki prensiplere ise daha sonraki yazılarımda değineceğim.
1. REP: The Reuse/Release Equivalence Principle
Yazılım tarihinde yeniden kullanılabilirliğin doruk zamanlarında yazılımcılık yapıyoruz. Npm, Nuget ve Bower gibi birçok paket yöneticisini bu amaçla kullanmaktayız. Yazılım modüllerinin yeniden kullanılabilirliği, nesne yönelimli programlamanın en önemli vaatlerinden biridir. Bizler de yazılım geliştirirken birçok bileşenimizi yeniden kullanılabilir olacak şekilde geliştirmek isteriz.
Geliştirdiğimiz ve kullandığımız bileşenler, versiyon numaralarına sahip olmadan yeniden kullanılabilir olamazlar. Çünkü bileşenler arasındaki uyumdan ancak versiyon numaraları sayesinde söz edilebilir. Hatta birçok yazılımcı bir bileşenin yeni bir versiyonu yayımlandığında onu kullanıp kullanmama kararını versiyon notlarına göre verir. Dolayısı ile bileşenler için versiyon numaraları çok önemlidir.
Mimari açıdan baktığımızda bileşen haline getirdiğimiz sınıflarımız birlikte yaygınlaştırılabilir olmalıdır.
Yani birlikte yaygınlaştırılacak sınıflar, aynı amaç için bir araya gelmiş olmalıdır. Bileşen farklı amaçlar için bir araya gelmiş, birbiriyle ilişkisi olmayan sınıflardan oluşmamalıdır. Birlikte yaygınlaştırılacak kadar yakın olmalılar birbirlerine.
REP İhlaline Somut Bir Örnek
İşi, Whatsapp gibi bir mesajlaşma uygulaması geliştirmek olan bir organizasyonun parçası olduğunuzu düşünün. Sizin ve ekibinizin görevi ise veri transferi ve şifreleme kısımlarını geliştirmek.
Veri transferi ve şifreleme ile alakalı sınıflarınızı bir bileşene koyduğunuzu varsayalım. Veri transferi sınıflarında yaptığınız bir değişikliği yaygınlaştırmak istediğinizde yeni versiyon yayımlayacaksınız. Yayımladığınız bu versiyon ile birlikte şifreleme sınıflarını da çıkmış olacaksınız.
Prensibi ihlal ettiğiniz için bileşeninizdeki şifreleme sınıflarını kullanan diğer ekipler, şifreleme sınıflarında hiçbir şey değişmediği halde yeni versiyon bildirimi alacaklar. Bu durum diğer ekipler için gereksiz efor ve bağımlılık demektir.
Bir bileşenin yeni versiyonu, bileşeni kullanan ekipler açısından anlamlı olmalıdır.
Kısaca; birbiri ile ilişkisi olmayan iki modülü tek bileşene koymak REP ihlalidir. Oysa bunlar birbirine çok da sıkı bağlı olmayan, bağımsız yaygınlaştırılabilecek modüllerdir.
Bu prensip çok açık fakat bir o kadar da soyut bir prensiptir. Daha iyi anlamak için CCP ve CRP’de incelenmelidir. CCP ve CRP bu prensibin daha net tanımıdır da diyebiliriz aslında. Bir sonraki yazımızın konusu da böylece belirlenmiş oldu.
(*) Robert C. Martin, Clean Architecture
