“Bildirim merkezi” modeli iyi veya kötü program tasarımını teşvik ediyor mu?


13

Bazen bu mesaj göbeği tarzı API'larla karşılaşıyorum, örneğin Cocoa NSNotificationCenter: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSNotificationCenter_Class/Reference/Reference.html

Genellikle bu API'lar, mesajlara / etkinliklere abone olduğunuz veya yayınladığınız global bir erişim noktası sağlar. Bağımlılık API açık değil, ancak kaynak kodunda gizli düz ve yapılandırılmamış bir program mimarisi teşvik çünkü bu bir sorun olduğunu düşünüyorum. Nesne sahipliği ve hiyerarşileri düşünmek zorunda değilsiniz, ancak programınızdaki herhangi bir nesnenin herhangi bir yerde herhangi bir kodla sonuçlanmasını sağlayabilirsiniz. Ama belki de bu iyi bir şeydir?

Bu model genellikle iyi veya kötü program tasarımını teşvik ediyor mu ve neden böyle? Kodu test etmeyi zorlaştırıyor veya kolaylaştırıyor mu?

Bu soru çok belirsiz veya genişse affet beni. Başımı böyle bir API'nin yaygın kullanımının potansiyel sonuçları ve onu kullanabileceğiniz farklı yollar etrafında sarmaya çalışıyorum.

Düzenleme: Bu model ile benim en büyük sorunum API bağımlılıklar ve nesne kuplajları hakkında "yalan" ve bu örnek ile gösterilebilir olduğunu tahmin:

myObj = new Foo();
myOtherObj = new Bar();
print myOtherObj.someValue; // prints 0
myObj.doSomething();
print myOtherObj.someValue; // prints 1, unexpectedly, because I never indicated that these objects had anything to do with each other

Bu örneği özellikle mi yoksa genel olarak dinleyici modelini mi soruyorsunuz?
TheLQ

Bunun dinleyici modelinden daha geniş olduğuna inanıyorum. Dinleyici modeli, iyi tanımlanmış bir nesne yapısı ve dinleyicilerin belirli nesneler üzerine kaydedilmesiyle "temiz" olarak uygulanabilir. Belirsizliğim, küresel mesaj / olay merkezi düzeni ile ilgili.
Magnus Wolffelt

Yanıtlar:


6

Kötü programlamayı teşvik ettiğini söyleyecek kadar ileri gitmem. Ancak kolayca yanlış kullanılabilir.

Peki gerçek fikir nedir?
Bildirimin kaynağı yalnızca bildirimde bulunur. Potansiyel gözlemcilerin ya da herhangi bir şeyin varlığı hakkında bir varsayımda bulunmaz. Bir gözlemci, işlemek üzere tasarlandığı bildirimlere kaydolur. Gözlemci, işleyebileceği bildirimler için kaç tane potansiyel kaynak olduğu konusunda herhangi bir varsayımda bulunmaz.

Bu, gözlemcileri veya gözlemcileri kaynakları bilmeden kaynaklara sahip olmadan bağımlılık enjeksiyonuna ulaşmanın bir yoludur. Bununla birlikte, tüm sistemin çalışması için, doğru bildirimler için doğru gözlemcileri bağlamanız gerekir ve bu sistem yazım hatalarına karşı bile savunmasızdır, çünkü derleme zamanı kontrol edilemez.

En büyük tehlike, birisinin bunu dünya çapında tonlarca nesneyi 1-1 çağrılar için kullanılabilir hale getirmesidir.


6

Asenkron mesajlaşma, ölçeklenmesi gereken büyük sistemler için iyi bir mimari prensiptir

Bunun Java eşdeğeri JMS'dir ve genellikle iyi bir şey olarak kabul edilir .

Bunun nedeni, iletiye gerçekten hizmet eden koddan istemci kodunuzun ayrılmasını teşvik etmesidir. Müşteri kodu sadece mesajlarını nereye göndereceğini bilmek zorundadır. Servis kodu sadece mesajları nereden alacağını bilmek zorundadır. Müşteri ve hizmet birbirinden hiçbir şey bilmez ve bu nedenle gerektiğinde birbirinden bağımsız olarak değişebilir.

İleti hub'ının URI'sini yapılandırmak ve kaynak koduna katıştırmamak için kolayca dışa aktarabilirsiniz.


4

Bu tipik bir Oberserver Pattern uygulamasıdır (veya bazen Listener kalıbı veya bazen Abone / Yayıncı kalıbı olarak da adlandırılır). Bunun davranışın faydalı olduğu uygulamalarda uygulanması iyi bir modeldir. Çözüme hiçbir değer katmazsa, hiçbir desen uygulanmamalıdır.

Sorunuzdan, sanki NotificationCenter hakkında her şeyin bildiği ve küresel şeylerin KÖTÜ olduğu konusunda endişeleriniz var gibi görünüyor. Bazen, evet, küresel şeyler kötüdür. Ama alternatife bakalım. Diyelim ki 2 bileşeniniz var, bu örnek için ne yaptıkları veya ne oldukları önemli değil. Bileşen1, üzerinde işlem yapılan veya bir şekilde değiştirilen bazı verilere sahiptir. Bileşen2, Compoent1 tarafından yönetilen türdeki verilerde yapılan herhangi bir değişiklik hakkında bilmek ister. Bileşen2, Bileşen1'in varlığını bilmeli mi? Veya Bileşen2'nin, uygulamadaki bir bileşenin ilgilendiği bazı verileri değiştirdiğini söyleyen bir iletiyi abone olması / dinlemesi daha iyi olur mu? Şimdi bu örneği alın ve düzinelerce veya daha fazla bileşenle çarpın ve desenin değerinin nerede olduğunu görebilirsiniz.

Her durum için mükemmel bir çözüm mü, hayır. Bileşenler arasındaki iletişimi soyutlaştırır ve daha gevşek bir bağlantı sağlar mı, evet.


1
Vikipedi'de okurken, gözlemci örüntü tanımının dünya çapında kullanılabilir bir olay merkezi içermediği görülüyor. Olay hub'ı ilgili tüm nesnelerin yapıcısına / yöntemine aktarıldıysa, bunu iyi bir model olarak kabul ederim. Gerçekten de beni belirsiz kılan, küresel erişim noktası ve durumu.
Magnus Wolffelt

0

Olay güdümlü sistemler için iyidir ve bir sürü Gözlemcinin birbirini gözlemlemesinin alternatifinden daha iyidir, çünkü olayları tetikleyen yanlışlıkla sonsuz gözlemci döngülerine girme olasılığınız daha düşüktür. Bu, olay işleyicileriyle birbirine bağlanabilen olay güdümlü ActiveX denetimleriniz olduğu eski VB günlerinde gerçek bir sorundu.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.