model view controller - pattern - Diferencia entre Observer, Pub/Sub y Enlace de datos

patterns design gof

Question

¿Cuál es la diferencia entre Observer Pattern , Publish/Subscribe y Data Binding ?

Busqué un poco en Stack Overflow y no encontré ninguna buena respuesta.

Lo que he llegado a creer es que el enlace de datos es un término genérico y existen diferentes formas de implementarlo, como el Patrón observador o el patrón Pub / Sub. Con el patrón Observer, un Observable actualiza sus Observadores. Con Pub / Sub, 0-muchos editores pueden publicar mensajes de ciertas clases y 0-muchos suscriptores pueden suscribirse a mensajes de ciertas clases.

¿Hay otros patrones de implementación de "enlace de datos"?

Answer 1

Aquí está mi opinión sobre los tres:

El enlace de datos

Esencialmente, en el núcleo esto simplemente significa que "el valor de la propiedad X en el objeto Y está semánticamente ligado al valor de la propiedad A en el objeto B. No se hacen suposiciones sobre cómo Y sabe o se alimenta cambios en el objeto B.

Observador u Observable / Observador

Un patrón de diseño mediante el cual un objeto está imbuido con la capacidad de notificar a otros sobre eventos específicos, normalmente se hace usando eventos reales, que son como ranuras en el objeto con la forma de una función / método específico. El observable es el que proporciona notificaciones, y el observador recibe esas notificaciones. En .net, el observable puede exponer un evento y el observador se suscribe a ese evento con un gancho con forma de "manejador de eventos". No se hacen suposiciones sobre el mecanismo específico con el que se producen las notificaciones, ni sobre el número de observadores que un observable puede notificar.

Pub / Sub

Otro nombre (quizás con más semántica de "transmisión") del patrón Observable / Observer, que generalmente implica un sabor más "dinámico": los observadores pueden suscribirse o anular la suscripción a notificaciones y un observable puede "gritar" a múltiples observadores. En .NET, uno puede usar los eventos estándar para esto, ya que los eventos son una forma de MulticastDelegate, y así pueden admitir la entrega de eventos a múltiples suscriptores, y también son compatibles con la cancelación de suscripción. Pub / Sub tiene un significado ligeramente diferente en ciertos contextos, que generalmente implica más "anonimato" entre el evento y la noche, lo que puede ser facilitado por cualquier cantidad de abstracciones, generalmente involucrando a algún "intermediario" (como una cola de mensajes) que sabe todo partes, pero las partes individuales no se conocen entre sí.

Enlace de datos, Redux

En muchos patrones "similares a MVC", el observable expone alguna forma de "notificación de cambio de propiedad" que también contiene información sobre la propiedad específica modificada. El observador está implícito, generalmente creado por el marco, y se suscribe a estas notificaciones a través de una sintaxis vinculante para identificar específicamente un objeto y propiedad, y el "controlador de eventos" solo copia el nuevo valor, lo que podría desencadenar cualquier actualización o lógica de actualización.

Enlace de datos re Redux

¿Una implementación alternativa para el enlace de datos? Ok, aquí hay una estúpida:

• se inicia un hilo de fondo que comprueba constantemente la propiedad vinculada en un objeto.
• si ese hilo detecta que el valor de la propiedad ha cambiado desde la última comprobación, copie el valor en el artículo encuadernado.

Answer 2

Estoy de acuerdo con su conclusión sobre ambos patrones, sin embargo, para mí, uso Observable cuando estoy en el mismo proceso y uso Pub / Sub en escenarios entre procesos, donde todas las partes solo conocen el canal común pero no las partes .

No conozco otros patrones, o déjenme decir de esta manera, nunca he necesitado otros patrones para esta tarea. Incluso la mayoría de los marcos de MVC y las implementaciones de enlace de datos generalmente usan internamente el concepto de observador.

Si está interesado en la comunicación entre procesos, le recomiendo:

"Patrones de integración empresarial: diseño, creación e implementación de soluciones de mensajería" - http://www.addison-wesley.de/9780321200686.html

Este libro contiene muchas ideas sobre cómo enviar mensajes entre procesos o clases que pueden usarse incluso en tareas de comunicación dentro del proceso (me ayudó a programar de una manera más flexible).

¡Espero que esto ayude!

Answer 3

Hay dos diferencias principales entre los patrones Observer / Observable y Publisher / Subscriber:

1. El patrón Observer / Observable se implementa principalmente de forma síncrona , es decir, el observable llama al método apropiado de todos sus observadores cuando ocurre algún evento. El patrón Publisher / Subscriber se implementa principalmente de forma asíncrona (utilizando la cola de mensajes).

2. En el patrón Observer / Observable , los observadores son conscientes de lo observable . Mientras que, en Publisher / Subscriber , los editores y suscriptores no necesitan conocerse entre sí . Simplemente se comunican con la ayuda de colas de mensajes.

Como mencionaste correctamente, el enlace de datos es un término genérico y puede implementarse utilizando el método Observador / Observable o Editor / Suscriptor. Data es el editor / suscriptor.

Answer 4

Me divierte que todas las respuestas intentaran explicar la sutil diferencia entre los patrones Observer y Pub / Sub sin dar ningún ejemplo concreto. Apuesto a que la mayoría de los lectores aún no saben cómo implementar cada uno leyendo uno es sincrónico y el otro es asincrónico.

Una cosa a tener en cuenta es: el objetivo de estos patrones es intentar desacoplar el código

El Observer es un patrón de diseño donde un objeto (conocido como sujeto) mantiene una lista de objetos que dependen de él (observadores), notificándoles automáticamente cualquier cambio de estado.

Patrón de observador

Esto significa que un observable object tiene una lista donde guarda todos sus observers (que generalmente son funciones). y puede atravesar esta lista e invocar estas funciones cuando se siente bien.

vea este ejemplo de patrón de observador para más detalles.

Este patrón es bueno cuando desea escuchar cualquier cambio de datos en un objeto y actualizar otras vistas de la interfaz de usuario de manera correspondiente.

Pero los Contras son Observables solo mantienen una matriz para mantener observadores (en el ejemplo, la matriz es Lista de observersList ).

NO distingue cómo se activa la actualización porque solo tiene una notify function , que activa todas las funciones almacenadas en esa matriz.

Si queremos agrupar manejadores de observadores basados ​​en diferentes eventos. Solo tenemos que modificar esa observersList de observersList a un Object como

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

mira este ejemplo pubsub para más detalles.

y la gente llama a esta variación como pub/sub . Entonces puede activar diferentes funciones basadas en los events que publicó.