Yazılım modülleri arasındaki bağlantı nasıl gevşetilir?

8.1 Ayrışma her şeydir

Netlik için, tartışılacak ana noktaları gösteren "Nesne Yönelimli Sistemlerin Ayrıştırılması" adlı iyi bir makaleden bir resim.

Hala bir uygulama mimarisi tasarlamanın kolay olduğunu düşünüyor musunuz?

8.2 Arayüzler, uygulama gizleme

Sistemin kuplajını azaltmak için ana prensipler, OOP prensipleri ve bunların arkasındaki Kapsülleme + Soyutlama + Polimorfizm prensibidir.

Bu yüzden:

• Modüller birbirleri için "kara kutular" olmalıdır (kapsülleme) . Bu, bir modülün başka bir modüle "tırmanmaması" ve onun iç yapısı hakkında hiçbir şey bilmemesi gerektiği anlamına gelir. Bir alt sistemdeki nesneler, başka bir alt sistemdeki nesnelere doğrudan erişmemelidir.
• Modüller/alt sistemler birbirleriyle yalnızca arayüzler (yani, uygulama ayrıntılarına bağlı olmayan soyutlamalar ) aracılığıyla etkileşime girmelidir. Buna göre, her modülün iyi tanımlanmış bir arayüzü veya diğer modüllerle etkileşim için arayüzleri olmalıdır.

"Kara kutu" (kapsülleme) ilkesi, her bir alt sistemin yapısını diğer alt sistemlerden bağımsız olarak değerlendirmemizi sağlar. Bir "kara kutu" olan modül nispeten serbestçe değiştirilebilir. Sorunlar yalnızca farklı modüllerin (veya bir modül ve ortamın) birleştiği yerde ortaya çıkabilir.

Ve bu etkileşim en genel (soyut) haliyle, yani bir arayüz şeklinde anlatılmalıdır. Bu durumda kod, arayüz sözleşmesine uyan herhangi bir uygulama ile aynı şekilde çalışacaktır. Polimorfizm adı verilen birleşik bir arayüz aracılığıyla farklı uygulamalarla (modüller veya nesneler) çalışabilme yeteneğidir.

Servlet'in bir arayüz olmasının nedeni budur : web kapsayıcısı, servlet'ler hakkında hiçbir şey bilmez, çünkü bunlar Servlet arayüzünü uygulayan bazı nesnelerdir ve hepsi bu. Servlet'ler ayrıca kabın yapısı hakkında da biraz bilgi sahibidir. Servlet arabirimi, Java web uygulamalarının dünyayı ele geçirmesi için gereken sözleşme, standart, minimum etkileşimdir.

Polimorfizm, bazen yanlışlıkla inanıldığı gibi yöntemlerin hiç de geçersiz kılınması değil, her şeyden önce, aynı arabirime veya "bir arabirim, birçok uygulamaya" sahip modüllerin / nesnelerin değiştirilebilirliğidir. Polimorfizmi uygulamak için kalıtım mekanizmasına hiç gerek yoktur. Bunu anlamak önemlidir, çünkü genel olarak kalıtımdan mümkün olduğunca kaçınılmalıdır .

Arayüzler ve polimorfizm sayesinde , zaten yazılanları değiştirmeden (Açık-Kapalı İlkesi) kodu değiştirme ve genişletme yeteneği tam olarak elde edilir.

Modüllerin etkileşimi yalnızca arayüzler biçiminde tanımlandığı ve belirli uygulamalara bağlı olmadığı sürece, sistem için kesinlikle "acı çekmeden" bir modülü aynı arayüzü uygulayan başka herhangi bir modülle değiştirme olanağına sahipsiniz. yeni bir tane ekleyin ve böylece işlevselliği genişletin.

LEGO yapıcısındaki gibidir - arayüz, etkileşimi standartlaştırır ve uygun bir konektöre sahip herhangi bir modülün bağlanabileceği bir tür konektör görevi görür.

Tasarımcının esnekliği, bir modülü veya parçayı aynı konektörlere (aynı arayüze sahip) sahip bir başkasıyla kolayca değiştirebilmemiz ve ayrıca istediğimiz kadar yeni parça ekleyebilmemiz (aynı zamanda mevcut parçalar değiştirilmez veya hiçbir şekilde değiştirilmez).

Arayüzler, her alt sistemi bir bütün olarak ele alarak ve iç yapısını göz ardı ederek daha basit bir sistem kurmanıza olanak tanır. Modüllerin etkileşime girmesine izin verir ve aynı zamanda birbirlerinin iç yapısı hakkında hiçbir şey bilmezler, böylece gevşek bağlantının temeli olan minimum bilgi ilkesini tam olarak uygularlar.

Arayüzler ne kadar genel/soyut tanımlanırsa ve etkileşime ne kadar az kısıtlama getirirlerse, sistem o kadar esnek olur. Buradan, SOLID'in prensiplerinden bir tanesi daha takip eder - "kalın arayüzlere" karşı çıkan Arayüz Ayrım Prensibi .

Büyük, hantal arayüzlerin daha küçük, daha spesifik olanlara bölünmesi gerektiğini, böylece küçük arayüzlerin (bağlı modüller) müşterilerinin yalnızca birlikte çalışmaları gereken yöntemleri bilmeleri gerektiğini söylüyor.

Bu ilke şu şekilde formüle edilmiştir: "Müşteriler, kullanmadıkları yöntemlere bağımlı olmamalıdır (yöntemlerin farkında olunmalıdır)" veya "Birçok özel arabirim, tek bir evrensel arabirimden daha iyidir".

Zayıf bağlantının, modüllerin etkileşimi ve bağımlılıkları, iç yapıları ve yapıları hakkında bilgi kullanılmadan yalnızca arayüzler, yani soyutlamalar yardımıyla açıklandığında sağlandığı ve aslında kapsüllemenin bu şekilde gerçekleştirildiği ortaya çıktı. Artı, farklı uygulamalar ekleyerek ve kullanarak, yani polimorfizm nedeniyle sistemin davranışını genişletme / değiştirme yeteneğine sahibiz. Evet, yine OOP - Kapsülleme, Soyutlama, Polimorfizm'e geldik.

8.3 Cephe: modül arayüzü

Burada deneyimli bir programcı soracaktır: Tasarım, karşılık gelen arabirimleri uygulayan nesneler düzeyinde değil, modüller düzeyindeyse, o zaman modül arabiriminin uygulanması nedir?

Cevap: tasarım kalıpları dilinde konuşursak, o zaman modül arayüzünün uygulanmasından özel bir nesne sorumlu olabilir - Cephe . Ağ Geçidi son ekini içeren bir nesnede (örneğin, MobileApiGateway) yöntemler çağırıyorsanız, bu büyük olasılıkla bir cephedir.

Cephe, belirli bir alt sistemle çalışmak için üst düzey bir dizi işlem biriktiren, iç yapısını ve arkasındaki gerçek karmaşıklığı gizleyen bir arayüz nesnesidir . Alt sistem uygulamasındaki değişikliklere karşı koruma sağlar. Tek bir giriş noktası görevi görür - "cepheyi tekmelersiniz ve o, ihtiyacı olanı elde etmek için bu alt sistemde kimin tekmelenmesi gerektiğini bilir."

Modülleri tasarlarken arayüz kavramını kullanmanıza ve böylece onları ayırmanıza izin veren en önemli tasarım modellerinden biri olan "Cephe" ile tanıştınız.

Ayrıca "Cephe", modüllerle sıradan nesnelerle aynı şekilde çalışmayı ve modülleri tasarlarken sınıfların tasarımında kullanılan tüm yararlı ilke ve teknikleri uygulamayı mümkün kılar.

Not : Çoğu programcı, sınıfları (nesneleri) tasarlarken arayüzlerin önemini anlasa da, görünüşe göre birçoğu arayüzleri modül düzeyinde kullanma fikrini de keşfediyor.