Pattern di osservatore: "Web of observers" - È mai usato?

0

Ho avuto un'idea (che sono sicuro che esiste già), per creare una sorta di "rete di osservatori / soggetti". Mi piacerebbe descrivere come funziona e poi fare diverse domande a riguardo.

Diciamo che abbiamo 5 oggetti: Oggetti A , B , C , D e E . Gli oggetti D e E devono osservare gli oggetti A , B e C .

Con il normale pattern Observer, sia D che E si registrano come osservatori per A , B e C . Ciò significa che D e E dovrebbero registrarsi tre volte in qualità di osservatori, creando un totale di sei relazioni soggetto-osservatore.

L'ideaèdiaggiungereunaltrooggettonelmezzo,chiamiamoloOggettoO.ImplementaentrambeleinterfacceObservereObservable.SiregistracomeosservatoredioggettiA,BeC.GlioggettiDeEsiregistranocomeosservatoriperl'oggettoO.

OgnivoltacheglioggettiA,BeCnotificanooggettoO,oggettoOnotificaaipropriosservatori-DeE.Cosìcreandounasortadirete.Questaretehauntotaledicinquerelazionisoggetto-osservatore.

Come vedo, questo ha due vantaggi principali:

  • Il vantaggio meno importante: questa soluzione consente di avere meno relazioni soggetto-osservatore, e quindi (penso) crea meno complessità nel sistema. In questa semplice descrizione il numero di relazioni si riduce solo di uno, ma più osservatori e soggetti ci sono, più grande è il vantaggio.

  • Il vantaggio più importante: considera un'applicazione con due gruppi di oggetti, gruppo A e gruppo B. Tutti gli oggetti nel gruppo A devono osservare tutti gli oggetti nel gruppo B . Se decidiamo di aggiungere un oggetto al gruppo B, piuttosto che usare regolarmente Observer dovremmo aggiornare un sacco di codice per registrare tutti gli oggetti nel gruppo A come osservatori del nuovo oggetto. Con la soluzione "rete" (che sono sicuro ha un nome diverso), registriamo solo l'oggetto "medio" (oggetto O ) come osservatore del nuovo oggetto nel gruppo B, e tutto gli oggetti nel gruppo A verrebbero notificati quando il nuovo oggetto nel gruppo B cambia stato.

Le mie domande:

  1. Questa soluzione è mai stata utilizzata in progetti professionali? hai mai incontrato questo in uso? O è solo un'idea interessante ma mai utilizzata in pratica?

  2. Che cosa diresti sono gli svantaggi di questo modello?

  3. Ha più vantaggi di cui non sono a conoscenza?

  4. Questo ha un nome?

posta Aviv Cohn 03.04.2014 - 23:19
fonte

1 risposta

3
  1. Certo, queste cose esistono. Viene in mente D-BUS , o qualsiasi numero di framework di messaggistica (RabbitMQ , AMQP , ZeroMQ , ecc.). Sono tutte variazioni su un tema simile.
  2. Maggiore latenza rispetto ai peer connessi direttamente e maggiore complessità per topologie complesse.
  3. Il più grande che riesco a pensare è la possibilità di estendere a più WAN e scalare fino a enormi numeri di abbonati. (Cerca 'message queue federation' per saperne di più). Inoltre, individuazione dei servizi . I client devono solo conoscere il componente "router" nel mezzo per connettersi a qualsiasi servizio.
  4. Ci sono così tante varianti che è difficile scegliere un singolo nome, ma io lo chiamerei "bus del messaggio del software" o "broker di messaggi".
risposta data 04.04.2014 - 02:13
fonte

Leggi altre domande sui tag