Doğrudan bağımlılıkları mesajlaşma ile değiştirme
Bazen bir modülün içinde bazı olayların/değişikliklerin meydana geldiğini diğerlerine bildirmesi yeterlidir ve bu bilgilere daha sonra ne olacağı önemli değildir.
Bu durumda, modüllerin "birbirlerini bilmesi", yani doğrudan bağlantılar içermesi ve doğrudan etkileşime girmesi gerekmez, ancak yalnızca mesaj (mesaj) veya olay (olay) alışverişi yapmak yeterlidir.
Bazen mesajlaşma yoluyla modül iletişiminin doğrudan bağımlılıktan çok daha zayıf olduğu görülüyor. Nitekim metotlar çağrılmadığı için sınıflar hakkında bilgi yoktur. Ama bu bir illüzyondan başka bir şey değil.
Yöntem adları yerine mantık, mesaj türlerine, bunların parametrelerine ve iletilen verilere bağlanmaya başlar. Bu tür modüllerin bağlantısı lekeli.
Eskiden şöyleydi: yöntemleri çağırıyoruz - bağlantı var, yöntemleri çağırmıyoruz - bağlantı yok. Şimdi A modülünün mesajlarında biraz farklı veriler göndermeye başladığını hayal edin. Ve aynı zamanda, bu mesajlara bağlı olan tüm modüller düzgün çalışmayacaktır.
Daha önce, yeni bir kullanıcı eklerken, yetkilendirme modülünün USER_ADDED mesajını gönderdiğini ve güncellemeden sonra, kayıt olmaya çalışırken bu mesajı göndermeye başladığını ve ayrıca parametrelerde başarılı kayıt olup olmadığını belirttiğini varsayalım.
Bu nedenle, mesaj mekanizmasını çok yetkin bir şekilde uygulamak çok önemlidir. Bunun için çeşitli şablonlar var.
Gözlemci. Birden çoğa bağımlılık durumunda, birçok modül birinin durumuna - ana olana - bağlı olduğunda kullanılır. Ana modülün tüm abonelerine aynı mesajları göndermesi anlamına gelen posta mekanizmasını kullanır ve bu bilgilerle ilgilenen modüller "abone" arayüzünü uygular ve posta listesine abone olur.
Bu yaklaşım, kullanıcı arayüzü olan sistemlerde yaygın olarak kullanılır ve uygulamanın çekirdeğinin (modelin) bağımsız kalmasına izin verirken, ilişkili arayüzlere bir şeylerin değiştiği ve güncellenmesi gerektiği konusunda bilgi verir.
Burada mesaj formatı, geliştiricilerin geriye dönük uyumluluk ve iyi dokümantasyonla ilgilenmesi gereken işletim sistemi düzeyinde standartlaştırılmıştır.
Mesajların dağıtımı yoluyla etkileşimin organizasyonunun ek bir "bonusu" vardır - "yayınlanan" (yani gönderilen) mesajlara "abonelerin" isteğe bağlı varlığı. Bunun gibi iyi tasarlanmış bir sistem, modüllerin herhangi bir zamanda eklenmesine/çıkarılmasına olanak tanır.
Mesajlaşma otobüsü
Mesaj alışverişini organize edebilir ve bunun için Mediator kalıbını farklı bir şekilde kullanabilirsiniz .
Modüller arasında çoktan çoğa bağımlılık olduğunda kullanılır. Arabulucu, modüller arasındaki iletişimde bir aracı görevi görür, bir iletişim merkezi görevi görür ve modüllerin açıkça birbirlerine atıfta bulunma ihtiyacını ortadan kaldırır.
Sonuç olarak, modüllerin birbirleriyle etkileşimi (“hepsi hepsiyle”), modüllerin yalnızca bir aracıyla (“biri hepsiyle”) etkileşimi ile değiştirilir. Arabulucunun, çoklu modüller arasındaki etkileşimi kapsadığı söylenir.
Bu sözde akıllı aracıdır . Geliştiricilerin çoğu zaman, belirli mesajları almayı açıp kapatarak bireysel modüllerin davranışını etkileyen koltuk değneklerini eklemeye başladıkları yer burasıdır.
Tipik bir gerçek hayat örneği, havaalanı trafik kontrolüdür. Uçaklardan gelen tüm mesajlar, doğrudan uçaklar arasında gönderilmek yerine kontrolörün kontrol kulesine gider. Ve kontrolör, hangi uçakların kalkabileceğine veya inebileceğine zaten karar veriyor ve karşılığında uçaklara mesajlar gönderiyor.
Önemli! Modüller birbirlerine sadece basit mesajlar değil, aynı zamanda komut nesneleri de gönderebilirler. Bu etkileşim, Komut şablonu tarafından açıklanır. Sonuç olarak, belirli bir eylemi gerçekleştirme isteğini ayrı bir nesne olarak kapsüllemektir.
Aslında, bu nesne , daha sonra bu eylemi bir parametre olarak yürütülmesi için diğer modüllere iletmenize ve genel olarak komut nesnesiyle sıradan nesneler üzerinde gerçekleştirilebilen herhangi bir işlemi gerçekleştirmenize izin veren tek bir execute() yöntemi içerir .
Demeter Kanunu
Demeter Yasası örtük bağımlılıkların kullanımını yasaklar: "A nesnesinin B nesnesine ve B nesnesinin C nesnesine erişimi varsa, A nesnesinin C nesnesine doğrudan erişememesi gerekir."
Bu, koddaki tüm bağımlılıkların "açık" olması gerektiği anlamına gelir - sınıflar / modüller çalışmalarında yalnızca "bağımlılıklarını" kullanabilir ve bunlar üzerinden başkalarına geçmemelidir. İyi bir örnek, üç katmanlı bir mimaridir. Arayüz katmanı, mantık katmanıyla birlikte çalışmalı, ancak doğrudan veritabanı katmanıyla etkileşime girmemelidir.
Kısaca, bu ilke şu şekilde de formüle edilmiştir: "Arkadaşların arkadaşlarıyla değil, yalnızca yakın arkadaşlarla etkileşim kurun." Bu, kodun daha az tutarlı olmasının yanı sıra tasarımında daha fazla görünürlük ve şeffaflık sağlar.
Demeter Yasası, gevşek bağlantının temeli olan ve bir nesnenin / modülün diğer nesnelerin / modüllerin yapısı ve özellikleri hakkında mümkün olduğunca az ayrıntı bilmesi gerektiği gerçeğinden oluşan, daha önce bahsedilen "minimum bilgi ilkesini" uygular ve kendi bileşenleri de dahil olmak üzere genel olarak herhangi bir şey .
Hayattan bir benzetme: Köpeğin koşmasını istiyorsanız, pençelerine komut vermek aptalcadır, komutu köpeğe vermek daha iyidir ve o pençeleriyle kendisi ilgilenecektir.
Kalıtım yerine kompozisyon
Bu çok geniş ve ilginç bir konu ve en azından ayrı bir dersi hak ediyor. İnternette bu konuda bir fikir birliğine varılana kadar birçok kopya kırıldı - kalıtımı minimumda, kompozisyonu - maksimumda kullanıyoruz.
Mesele şu ki, kalıtım aslında sınıflar arasındaki en güçlü bağlantıyı sağlıyor, bu yüzden bundan kaçınılmalıdır. Bu konu, Herb Sutter'ın " Miras Üzerine Kompozisyonu Tercih Et " başlıklı makalesinde iyi bir şekilde ele alınmıştır.
Tasarım kalıplarını öğrenmeye başladığınızda, bir nesnenin veya onun iç yapısının yaratılmasını yöneten bir sürü kalıpla karşılaşacaksınız. Bu arada bu bağlamda oyunlardan gelen Delegate/Delegate kalıbına ve Component kalıbına dikkat etmenizi tavsiye edebilirim .
Desenler hakkında biraz sonra daha fazla konuşacağız.