Apakah pola "pusat notifikasi" mendorong desain program yang baik atau buruk?

Kadang saya menemukan API gaya hub-pesan ini, misalnya Cocoa NSNotificationCenter: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSNotificationCenter_Class/Reference/Reference.html

Biasanya API ini menyediakan titik akses global tempat Anda berlangganan atau menyiarkan pesan / acara. Saya pikir ini adalah masalah karena mendorong arsitektur program yang datar dan tidak terstruktur, di mana dependensi tidak eksplisit dalam API, tetapi disembunyikan dalam kode sumber. Anda tidak dipaksa untuk berpikir tentang kepemilikan objek dan hierarki, tetapi lebih suka membuat objek apa pun dalam program Anda menghasilkan kode apa pun di mana pun dipanggil. Tapi mungkin ini hal yang baik?

Apakah pola ini umumnya mendorong desain program yang baik atau buruk, dan mengapa demikian? Apakah ini membuat kode lebih sulit atau lebih mudah untuk diuji?

Maafkan saya jika pertanyaan ini terlalu kabur atau luas. Saya mencoba merangkul kepala saya di sekitar konsekuensi potensial dari penggunaan API yang luas seperti ini, dan berbagai cara Anda dapat menggunakannya.

Sunting: Saya kira masalah terbesar saya dengan pola ini adalah bahwa API "terletak" tentang dependensi dan sambungan objek, dan dapat diilustrasikan dengan contoh ini:

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

Saya tidak akan mengatakan bahwa itu mendorong pemrograman yang buruk. Tapi itu bisa dengan mudah disalahgunakan.

Nah apa ide sebenarnya?
Sumber notifikasi hanya membuat notifikasi. Itu tidak membuat asumsi tentang keberadaan pengamat potensial atau apa pun. Pengamat mendaftar untuk pemberitahuan yang dirancang untuk ditangani. Pengamat tidak membuat asumsi tentang berapa banyak sumber potensial yang ada untuk pemberitahuan yang mungkin ditangani.

Ini adalah cara untuk mencapai injeksi ketergantungan, tanpa pernah memiliki sumber tahu pengamat atau pengamat tahu sumber. Namun untuk keseluruhan sistem agar berfungsi, Anda perlu memasang pengamat yang tepat untuk pemberitahuan yang benar, dan sistem ini bahkan rentan terhadap kesalahan pengetikan, karena tidak dapat dikompilasi dengan waktu diperiksa.

Bahaya terbesar tentu saja adalah, bahwa seseorang akan menggunakan ini untuk membuat banyak objek tersedia secara global untuk 1-1 panggilan.

Pesan asinkron adalah prinsip arsitektur yang bagus untuk sistem besar yang harus berskala

Setara dengan Java ini adalah JMS dan umumnya dianggap sebagai hal yang baik .

Ini karena mempromosikan decoupling kode klien Anda dari kode yang benar-benar melayani pesan. Kode klien hanya harus tahu di mana memposting pesan mereka. Kode layanan hanya harus tahu di mana mengambil pesan. Klien dan layanan tidak mengenal satu sama lain dan oleh karena itu dapat berubah secara independen satu sama lain seperti yang dipersyaratkan.

Anda dapat dengan mudah mengeluarkan URI hub pesan untuk membuatnya dapat dikonfigurasi dan tidak tertanam dalam kode sumber.

Ini adalah implementasi Pola Oberserver yang khas (atau kadang-kadang disebut pola Pendengar atau kadang-kadang disebut pola Pelanggan / Penerbit). Dalam aplikasi yang bermanfaat bagi perilaku, ini merupakan pola yang baik untuk diterapkan. Tidak ada pola yang harus diterapkan jika tidak menambah nilai pada solusi.

Dari pertanyaan Anda, sepertinya Anda khawatir bahwa semuanya tahu tentang Pusat Pemberitahuan dan bahwa hal-hal global BURUK. Terkadang, ya, hal-hal global buruk. Tapi mari kita lihat alternatifnya. Katakanlah Anda memiliki 2 komponen, untuk contoh ini tidak terlalu penting apa yang mereka lakukan atau apa adanya. Komponen1 memiliki beberapa data yang ditindaklanjuti atau diubah dalam beberapa cara. Component2 ingin tahu tentang perubahan apa pun pada data dari jenis yang dikelola Compoent1. Haruskah Komponen2 tahu tentang keberadaan Component1? Atau akan lebih baik untuk Component2 berlangganan / dengarkan pesan yang memberitahukannya bahwa beberapa komponen di suatu tempat di aplikasi mengubah beberapa data yang ia minati? Sekarang ambil contoh ini dan kalikan dengan lusinan atau lebih komponen dan Anda dapat melihat di mana nilai pola terletak.

Apakah ini solusi sempurna untuk setiap situasi, tidak. Apakah ini komunikasi abstrak di antara komponen dan memberikan kopling yang lebih longgar, ya.

Ini bagus untuk sistem yang digerakkan oleh peristiwa, dan lebih bagus daripada alternatif untuk memiliki sekelompok Pengamat yang saling mengamati, karena Anda cenderung tidak akan berakhir dengan loop tak terbatas dari pengamat peristiwa penembakan yang tidak disengaja. Ini adalah masalah nyata di masa lalu VB, ketika Anda memiliki kontrol ActiveX yang digerakkan oleh peristiwa yang dapat dihubungkan satu sama lain dengan pengendali acara.