Il modello del "centro di notifica" incoraggia una progettazione del programma buona o cattiva?

Non oserei dire che incoraggia la cattiva programmazione. Ma può essere facilmente abusato.

Bene, qual è l'idea reale?
La fonte della notifica fa solo la sua notifica. Non fa una supposizione sull'esistenza di potenziali osservatori o altro. Un osservatore si registra per le notifiche che è stato progettato per gestire. L'osservatore non fa alcuna ipotesi su quante fonti potenziali ci siano per le notifiche che può gestire.

Questo è un modo per ottenere l'iniezione di dipendenza, senza aver mai le fonti che sanno che gli osservatori o gli osservatori conoscono le fonti. Tuttavia, per il funzionamento dell'intero sistema, è necessario collegare gli osservatori giusti per le notifiche corrette e questo sistema è persino vulnerabile agli errori di battitura, perché non può essere controllato per il tempo di compilazione.

Il più grande pericolo, naturalmente, è che qualcuno lo userà per creare tonnellate di oggetti globalmente disponibili per le chiamate 1-1.

La messaggistica asincrona è un buon principio architettonico per i sistemi di grandi dimensioni che devono ridimensionare

L'equivalente Java di questo è JMS e generalmente considerato come una buona cosa .

Questo perché promuove il disaccoppiamento del codice cliente dal codice che effettivamente fornisce il messaggio. Il codice cliente deve semplicemente sapere dove pubblicare il loro messaggio. Il codice di servizio deve semplicemente sapere dove raccogliere i messaggi. Il cliente e il servizio non conoscono l'un l'altro e quindi possono cambiare indipendentemente l'uno dall'altro a seconda delle esigenze.

È possibile esternare facilmente l'URI dell'hub dei messaggi per renderlo configurabile e non incorporato nel codice sorgente.

Si tratta di un'implementazione tipica del modello Oberserver (o talvolta chiamata pattern Listener o talvolta denominata modello Subscriber / Publisher). Nelle applicazioni in cui questo comportamento è utile è un buon modello da implementare. Nessun modello dovrebbe essere implementato se non aggiunge alcun valore alla soluzione.

Dalla tua domanda, sembra che tu sia preoccupato che tutto sia a conoscenza di NotificationCenter e che le cose globali siano BAD. A volte, sì, le cose globali sono cattive. Ma guardiamo l'alternativa. Diciamo che hai 2 componenti, per questo esempio non importa quello che fanno o quello che sono. Component1 ha alcuni dati che sono stati applicati o modificati in qualche modo. Component2 vorrebbe sapere di eventuali modifiche ai dati del tipo gestito da Compoent1. Component2 dovrebbe conoscere l'esistenza di Component1? O sarebbe meglio per Component2 iscriversi / ascoltare un messaggio che dice che alcuni componenti nell'app hanno cambiato alcuni dati a cui sono interessati? Ora prendi questo esempio e moltiplicalo per dozzine o più componenti e puoi vedere dove si trova il valore del modello.

È una soluzione perfetta per ogni situazione, no. Rende astratta la comunicazione tra i componenti e fornisce un accoppiamento più libero, sì.

È buono per i sistemi basati sugli eventi ed è più bello dell'opportunità di avere un gruppo di osservatori che si osservano a vicenda, poiché è meno probabile che si finisca con involontari loop infiniti di eventi di fuoco degli osservatori. Questo era un problema reale nei vecchi giorni VB, quando i controlli ActiveX basati su eventi potevano essere collegati tra loro con i gestori di eventi.