Kalite#5 — Değişimin Bütünlüğü (The Common Closure Principle)

Geliştirdiğimiz birçok uygulama için bakım yapılabilirlik çok önemlidir. Hatta yazılımcılar olarak vaktimizin çoğunu mevcut bir uygulamada değişiklikler yaparak geçiririz. Çoğumuzun pek sevmediği bir durumdur bu. Üstelik değişiklik yaptığımız kısımları daha önce bir başkası geliştirmişse (ki çoğu zaman öyledir:) değişim süreci baya stresli geçer. Fakat ister bizim geliştirdiğimiz bir yazılım olsun isterse başkasından devraldığımız bir yazılım olsun değişim kaçınılmazdır.

Değişim kaçınılmazdır, o zaman adapte ol!

Bir önceki yazımızda bileşenleri nasıl kurgulamamız gerektiğinden bahsetmiştik ve The Reuse/Release Equivalence Principle(REP) konusunda birlikte yaygınlaştırılabilirlik açısından sınıflarımızı aynı bileşene koymamız gerektiğini söylemiştik.

The Common Closure Principle, aynı sebeplerle ve aynı zamanlarda değişen sınıflarımızın aynı bileşende olması gerektiğini söyler.

Yazılımcı olarak bizlerden bir değişiklik talep edildiğinde ilk olarak hangi bileşenleri etkilediğini düşünmeye çalışırız. Değişiklik yapmamız gereken bileşen sayısının minimum olması ise her zaman işimizi kolaylaştırır. Tek bir bileşende değişiklik yapmamız gerekiyorsa işimiz bir anda kolaylaşıverir. Çünkü tek bir bileşeni değiştirmek, test etmek ve yaygınlaştırmak her zaman daha kolaydır.

İşte yazılımcılardaki değişimin dar bir alanda kalması isteğinin prensibe dönüşmüş hali CCP’dir. Dolayısı ile daha bileşenler tasarlanırken değişimler öngörülerek aynı sebeplerle değişecek sınıfların aynı bileşenlere yerleştirilmesi işlerimizi ciddi anlamda kolaylaştıracaktır.

CCP, SOLID prensiplerinden The Single Responsibility Principle ile neredeyse aynıdır diyebiliriz. Tek fark SRP, sınıflar için geçerli iken CCP, bileşenler için geçerlidir. SRP’ye daha sonra SOLID prensiplerini işlerken değineceğiz.

CCP İhlaline Somut Bir Örnek

Yine bir önceki yazımızda verdiğimiz örnekte olduğu gibi işi, Whatsapp gibi bir mesajlaşma uygulaması geliştirmek olan bir organizasyonun parçası olduğunuzu düşünün. Fakat bu defa sizin ve ekibinizin görevi gönderilen resim ve video gibi media içeriklerinin sıkıştırılması olsun.

Resim ve video dosyaları yapıları itibari ile farklı sıkıştırılma teknikleri ile sıkıştırılabilirler. Dolayısı ile her iki farklı media türü için farklı sıkıştırma sınıflarına sahip olursunuz. Bu sınıfları farklı bileşenlerde sakladığınızı düşünün. İşte CCP’yi ihlal ettiğiniz kısım tam olarak burası. Çünkü her ne kadar farklı tekniklerle sıkıştırma yapıyor olsanız bile gelebilecek değişiklik talepleri çoğunluklu her iki bileşeninizi de etkileyecektir. Bu tür bir değişiklik talebi her defasında iki bileşende değişiklik yapmanızı, iki bileşende testler yapmanızı ve ikisini birden yaygınlaştırmanızı gerektirecektir. Bu nedenle daha en baştan bu tür değişimlerin bileşenler üzerindeki etkisini bölmemek adına tek bir bileşende tüm sıkıştırma işlemlerinizi yapmanız daha uygun olacaktır. Bu şekilde değişimlerin bütünlüğünü sağlamış olursunuz.

Özetle; bir değişiklik minimum sayıda bileşeni etkilemelidir. Dolayısıyla sınıflarımızın bileşenlere dağılımları değişiklik talepleri de göz önünde bulundurularak yapılmalıdır.

(*) Robert C. Martin, Clean Architecture