Differenza tra Observer, Pub / Sub e Data Binding

Qual è la differenza tra Observer Pattern , Publish / Subscription e Data Binding ?

Ho cercato un po 'in giro su Stack Overflow e non ho trovato buone risposte.

Ciò a cui sono giunto a credere è che l'associazione dati è un termine generico e ci sono diversi modi per implementarlo come l'Observer Pattern o il Pub / Sottotitolo. Con il modello Observer, un osservabile aggiorna i suoi osservatori. Con Pub / Sub, 0-molti editori possono pubblicare messaggi di determinate classi e 0-molti abbonati possono iscriversi ai messaggi di determinate classi.

Esistono altri schemi di implementazione dell '"associazione dati"?

Ecco la mia opinione sui tre:

Associazione dati

In sostanza, questo significa semplicemente "il valore della proprietà X sull'oggetto Y è semanticamente legato al valore della proprietà A sull'oggetto B. Non vengono fatte ipotesi su come Y sappia o venga alimentato le modifiche sull'oggetto B.

Osservatore o osservabile / osservatore

Un modello di progettazione in base al quale un oggetto è impregnato della capacità di notificare ad altri eventi specifici, generalmente fatto utilizzando eventi reali, che sono in qualche modo simili a slot nell'oggetto con la forma di una specifica funzione / metodo. L'osservabile è colui che fornisce le notifiche e l'osservatore riceve tali notifiche. In .net, l'osservabile può esporre un evento e l'osservatore si iscrive a quell'evento con un hook a forma di "gestore di eventi". Non vengono fatte ipotesi sul meccanismo specifico che le notifiche si verificano, né sul numero di osservatori che un osservabile può notificare.

Pub / Sub

Un altro nome (forse con più semantica "broadcast") del modello Osservabile / Osservatore, che di solito implica un sapore più "dinamico": gli osservatori possono iscriversi o annullare l'iscrizione alle notifiche e un osservabile può "gridare" a più osservatori. In .NET, è possibile utilizzare gli eventi standard per questo, poiché gli eventi sono una forma di MulticastDelegate e quindi possono supportare la consegna di eventi a più abbonati e supportare anche la disiscrizione. Pub / Sottotitoli ha un significato leggermente diverso in alcuni contesti, di solito comportando più "anonimato" tra evento ed eventer, che può essere facilitato da un numero qualsiasi di astrazioni, di solito coinvolge un "intermediario" (come una coda di messaggi) che conosce tutto parti, ma le singole parti non si conoscono.

Rilegatura dati, Redux

In molti modelli "simili a MVC", l'osservabile espone una sorta di "notifica di modifica della proprietà" che contiene anche informazioni sulla specifica proprietà modificata. L'osservatore è implicito, solitamente creato dal framework, e sottoscrive queste notifiche tramite una sintassi vincolante per identificare in modo specifico un oggetto e una proprietà, e il "gestore di eventi" copia semplicemente il nuovo valore, attivando potenzialmente qualsiasi aggiornamento o logica di aggiornamento.

Rilegatura dati su Redux

Un'implementazione alternativa per l'associazione dei dati? Ok, eccone uno stupido:

• viene avviato un thread in background che controlla costantemente la proprietà associata su un oggetto.
• se quel thread rileva che il valore della proprietà è cambiato dall'ultimo controllo, copia il valore sull'elemento associato.

Esistono due differenze principali tra i modelli Observer / Observable e Publisher / Subscriber:

1. Il modello di osservatore / osservabile è per lo più implementato in modo sincrono , cioè l'osservabile chiama il metodo appropriato di tutti i suoi osservatori quando si verifica un evento. Il modello di Publisher / Sottoscrittore viene implementato principalmente in modo asincrono (usando la coda dei messaggi).

2. Nel modello Osservatore / Osservabile , gli osservatori sono consapevoli dell'osservabile . Mentre in Publisher / Sottoscrittore , editori e abbonati non devono conoscersi . Comunicano semplicemente con l'aiuto di code di messaggi.

Come indicato correttamente, l'associazione dei dati è un termine generico e può essere implementato utilizzando il metodo Observer / Observable o Publisher / Subscriber. I dati sono l'editore / abbonato.

Sono un po 'divertito dal fatto che tutte le risposte qui stessero cercando di spiegare la sottile differenza tra i modelli Observer e Pub / Sub senza fornire esempi concreti. Scommetto che la maggior parte dei lettori non sa ancora come implementare ognuno leggendo uno è sincrono e l'altro è asincrono.

Una cosa da notare è: l'obiettivo di questi schemi è cercare di disaccoppiare il codice

L'Osservatore è un modello di progettazione in cui un oggetto (noto come soggetto) mantiene un elenco di oggetti a seconda di esso (osservatori), notificandoli automaticamente di eventuali cambiamenti di stato.

Modello di osservatore

Questo significa che observable objectha un elenco in cui mantiene tutto observers(che di solito sono funzioni). e può attraversare questo elenco e invocare queste funzioni quando ci si sente bene.

vedere questo esempio di modello di osservatore per i dettagli.

Questo modello è utile quando si desidera ascoltare eventuali modifiche dei dati su un oggetto e aggiornare le altre viste dell'interfaccia utente di conseguenza.

Ma i contro sono osservabili mantengono solo un array per mantenere gli osservatori (nell'esempio, l'array è observersList).

NON distingue come viene attivato l'aggiornamento perché ne ha solo uno notify function, che attiva tutte le funzioni memorizzate in quell'array.

Se vogliamo raggruppare i gestori degli osservatori in base a eventi diversi. Dobbiamo solo modificarlo observersListin modo Objectsimile

var events = {
    "event1": [handler1, handler2],
    "event2": [handler3]
}

vedi questo esempio di pubsub per i dettagli.

e la gente chiama questa variazione come pub/sub. Quindi puoi attivare diverse funzioni in base a quelle che eventshai pubblicato.

Sono d'accordo con le tue conclusioni su entrambi i modelli, tuttavia, per me, utilizzo Osservabile quando sono nello stesso processo e utilizzo Pub / Sub in scenari tra processi, in cui tutte le parti conoscono solo il canale comune ma non le parti .

Non conosco altri schemi o, per così dire, non ho mai avuto bisogno di altri schemi per questo compito. Anche la maggior parte dei framework MVC e delle implementazioni di associazione dei dati usano generalmente internamente il concetto di osservatore.

Se sei interessato alla comunicazione tra processi, ti consiglio di:

"Modelli di integrazione aziendale: progettazione, costruzione e distribuzione di soluzioni di messaggistica" - http://www.addison-wesley.de/9780321200686.html

Questo libro contiene molte idee su come inviare messaggi tra processi o classi che possono essere utilizzate anche in attività di comunicazione intra-processo (mi ha aiutato a programmare in modo più libero).

Spero che aiuti!