"Merhaba Amigo! Size OOP'nin bir başka avantajından bahsetmek istiyorum. Gördüğünüz gibi programlar binalardan çok hayvanlar gibidir. Onlar inşa edilmezler, büyürler. Gelişim sürekli değişim demektir . iyi bir planınız olsun ve sonuna kadar izleyin. Ancak yazılım geliştirmede durum böyle değil."

Çoğu zaman, bir şeyi istediğiniz gibi yapamazsınız ve programınızı birçok kez elden geçirmeniz gerekir. Ve daha da sık olarak, müşterinin gereksinimleri değişir.

"Peki ya müşteri gerçekten ayrıntılı bir teknik özellik sağlarsa?"

"Zaman içinde neler olduğuna bir bakın. Bir ürün başarılı olursa, müşteri yeni bir sürüm yayınlamak isteyecektir, ardından bir tane daha ve bir tane daha. Ve elbette, birkaç « küçük değişiklik » yapmanız gerekecek . mevcut ürün. Yani yazılım geliştirme, uzun bir değişiklikler dizisidir. Yalnızca temposu farklıdır. Her hafta, ayda bir veya altı ayda bir yeni bir sürüm yayınlanabilir."

Java university

"Peki bütün bunlardan ne sonuç çıkarıyoruz?"

"Ürünün iç yapısı, minimum yeniden çalışma ile büyük (ve küçük) değişikliklerin yapılmasına izin verecek şekilde korunmalıdır."

"Bunu nasıl yaptın?"

"Bir programın birbiriyle etkileşime giren nesnelerden nasıl oluştuğundan daha önce bahsetmiştik. Tahtada programımızın tüm nesnelerini temsil etmek için kalın noktalar kullanalım. Her nesneden tüm nesnelere oklar (nokta) çizeceğiz. etkileşimde bulunduğu (noktalar).

Şimdi nesneleri (noktaları) gruplar halinde birleştirelim. Noktalar, birbirlerine diğer noktalardan çok daha fazla bağlıysa, aynı gruba aittir. Bir noktanın oklarının çoğu, kendi grubundaki noktaları gösteriyorsa, nesneleri doğru şekilde gruplandırmışsınız demektir. Aynı grup içindeki noktalar sıkı bir şekilde birleştirilirken, farklı gruplardaki noktalar gevşek bir şekilde birleştirilir.

Buna « gevşek bağlantı ilkesi » denir . Bir program, mantığı kendi iç yapılarına güçlü bir şekilde bağlı ve diğer katmanlara/parçalara zayıf bir şekilde bağlı olan, genellikle katmanlar olmak üzere birkaç parçaya bölünmüştür. Katmanlar arasındaki etkileşim genellikle oldukça bölümlere ayrılmıştır. Bir katman, sınıflarının yalnızca küçük bir alt kümesini kullanarak başka bir katmanı çağırabilir.

"Aynı 'işbölümü' ilkesi, ama daha geniş ölçekte mi?"

"Kesinlikle. Bu, bir departmanı yeniden düzenlememize, daha verimli hale getirmemize ve daha fazla insanı işe almamıza olanak tanıyor ve departmanlar arası protokolleri değiştirmezsek, tüm değişikliklerimiz yerel olacak. Kimsenin yeniden eğitilmesi gerekmiyor. Biz yapmıyoruz" Tüm sistemi yeniden çalışmak zorunda değilsiniz. Departmanlar arası etkileşim mekanizmaları iyi seçilirse, her departman kendi iç işlerini bu şekilde optimize edebilir."

"Eğer iyi seçilirlerse. Peki ya iyi seçilmezlerse?"

"O zaman, değişiklik yapmak için « kıpırdatma alanınız » hızla tükenecek ve tüm sistemi yeniden çalışmak zorunda kalacaksınız. Bu zaman zaman olur. Geleceği tahmin edemeyiz, ancak programı yeniden yazmamız gereken sayıyı en aza indirebiliriz."

"Tamam. Programı bu şekilde bölmenin faydasını görüyorum ama OOP nasıl ortaya çıkıyor?"

"Departmanları nasıl yapılandıracağımızı ve nasıl etkileşim kuracaklarını seçtiğimizde, ' soyutlama ilkesini ' uyguluyoruz. Programlamada soyutlama, programı bölmenin en iyi yolunu ve parçaların nasıl etkileşimde bulunması gerektiğini belirlemek için kullanılır. Bu ilke, programı bireysel sınıflara ayırana kadar onu oluşturan parçalara da tekrar tekrar uygulanacaktır."

"Ve bu parçaların iç yapısını gizlemek ve diğer parçalarla nasıl etkileşim kurduklarını kesin olarak sınırlamak - bu kapsülleme , değil mi?"

"Kesinlikle. Kapsülleme ve soyutlama, OOP'nin temel taşlarıdır. İyi bir program bu iki ilkeye bağlı kalmalıdır. Daha sonra diğer ilkelere bir göz atıp avantajlarını anlamaya başlayacağız."

"İyi şeyler. Bekleyemem!"