Kalite#6 — Bileşenler ve Bağımlılık (The Common Reuse Principle)
Daha önceki yazılarımda The Reuse/Release Equivalence Principle(REP) ve The Common Closure Principle(CCP)’den bahsetmiştim. Bileşen oluşturma konusunda değineceğimiz son prensip The Common Reuse Principle(CRP) olacak.
REP ve CCP prensipleri bize hangi sınıfların hangi bileşenlere koyulması gerektiğini söylüyordu. CRP ise aynı şeyi tersten söyler. Yani hangi sınıfları hangi bileşene koymamamız gerektiğini.
Don’t depend on things you don’t need
Bir bileşenin kullanıcılarını ihtiyaçları olmayan şeylere bağımlı kılmayın der CRP. Yani bir araya getirip bileşen yaptığınız sınıflar birlikte kullanılabilecek kadar akraba olmalıdır. Birbirine sıkı bağlı olmayan sınıflar bir arada olmamalıdır.
CRP İhlaline Somut Bir Örnek
Yine önceki yazılarımızda verdiğimiz örneklerde olduğu gibi işi, Whatsapp gibi bir mesajlaşma uygulaması geliştirmek olan bir organizasyonun parçası olduğunuzu düşünün.
Veri transferi ve video işlemleri için geliştirilen sınıfların aynı bileşene koyulduğunu varsayalım. Zaten ikisinin bir arada bulunması çok net bir şekilde alakasız duruyor. Bu modüllerden herhangi birini kullanan başka bir bileşen gereksiz bir şekilde diğerine de bağımlı hale gelir. Bu bileşende yapılacak her değişiklikten ilgisi olmasa dahi bağımlı tüm bileşenler etkilenecektir. Dolayısı ile her yaygınlaştırmada ekstra bir efor kaybına sebep olacaktır.
REP, CCP ve CRP Arasındaki Denge
Farkettiyseniz eğer REP ve CCP, bileşenleri büyütme eğilimindeyken CRP bileşenleri küçültme eğilimindedir.
Üç prensibi de tamamen uygulamak imkansız ve aynı zamanda yanlış bir uygulamadır. Bu prensipler arasında bir denge kurulmalıdır. İşte bu noktada kuracağınız mimarinin ihtiyaçları, sizin mimari tecrübeniz ve becerileriniz devreye giriyor. Doğru noktayı belirlemek size kalmış durumda.
Aşağıda bu üç prensip arasındaki dengeyi görselleştirmeye çalıştım. Eğer bir prensibi ihlal edip diğer iki prensibe çok yüklenirseniz ihlal ettiğiniz prensibin karşısında yazan sorunla karşılaşmaya başlarsınız. Doğru nokta sizin mimarinizin ihtiyaçlarına göre ortalarda bir yerlerde. Zamanla uygulamanızın ihtiyaçlarına göre bu nokta dinamik olarak değişebilir.
Diyelimki REP ve CCP’ye fazlaca uydunuz ve birlikte kullanılmayacak sınıfları bir araya getirerek CRP’yi ihlal ettiniz. Bu durumda yaygınlaştırma sayınız artacaktır ve bu da size gereksiz bir maliyet oluşturacaktır.
REP ve CRP’yi fazlaca uygulayarak ve değişimleri pek hesaba katmayarak CCP’yi ihlal ettiniz diyelim. Bu durumda da her bir değişiklikte çok fazla bileşen etkilenecektir. Çünkü aynı sebepten değişen sınıfları aynı bileşene koymadınız.
Son olarak CCP ve CRP’yi fazlaca uygulayarak ve yaygınlaştırmaları hesaba katmayarak REP’i ihlal ettiniz diyelim. Bu durumda ise bileşenlerinizin yeniden kullanılabilirliği azalmış olacaktır.
Projenin ilk dönemlerinde bileşenlerde çok sık değişiklik yaşanacağı için genelllikle CCP daha çok uygulanır. Çünkü ilk zamanlar geliştirilebilirlik daha önemlidir. Fakat zamanla yeniden kullanılabilirlik ve yaygınlaştırmalar göz önünde bulundurularak diğer prensiplerle mimari dengelenmeye başlar. Olgunluk döneminde ise bu üç prensip arasında ciddi bir denge kurulmuş olur.
Bileşenleri Kurgulamanın Özeti
Son 3 yazıda bileşenlerimizi nasıl kurgulayacağımız ile alakalı 3 prensipten bahsettim. Bu 3 prensip birbirine benzer kuralları farklı açılardan dile getirmektedir. Bu prensipleri birbirini dengeleyecek şekilde kullanarak bileşenlerimizin doğru tasarlandığından emin olabiliriz.
Bundan sonra bileşenler arası ilişkileri düzenleyen prensipleri işleyeceğim. Daha sonraki yazılarda görüşmek üzere.
(*) Robert C. Martin, Clean Architecture
