Solución:
Hay dos diferencias principales entre los patrones de observador / observable y de editor / suscriptor:
-
Observador / Observable patrón se implementa principalmente en un sincrónico manera, es decir, lo observable llama al método apropiado de todos sus observadores cuando ocurre algún evento. los Editor / suscriptor patrón se implementa principalmente en un asincrónico way (usando la cola de mensajes).
-
En el Observador / Observable patrón, el los observadores son conscientes de lo observable. Mientras en Editor / suscriptor, editores y suscriptores no necesitan conocerse. Simplemente se comunican con la ayuda de colas de mensajes.
Como mencionó correctamente, el enlace de datos es un término genérico y se puede implementar utilizando el método Observer / Observable o Publisher / Subscriber. Los datos son el editor / observable.
Aquí está mi opinión sobre los tres:
El enlace de datos
Esencialmente, en el núcleo, esto solo 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 de los cambios en el objeto B.
Observador u Observable / Observador
Un patrón de diseño mediante el cual un objeto está imbuido de la capacidad de notificar a otros sobre eventos específicos, que generalmente se realiza utilizando 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, lo observable puede exponer un evento y el observador se suscribe a ese evento con un gancho en forma de “controlador de eventos”. No se hacen suposiciones sobre el mecanismo específico por 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 cancelar la suscripción a notificaciones y un observable puede “gritar” a múltiples observadores. En .NET, se pueden usar los eventos estándar para esto, ya que los eventos son una forma de MulticastDelegate y, por lo tanto, pueden admitir la entrega de eventos a múltiples suscriptores y también admitir la cancelación de la suscripción. Pub / Sub tiene un significado ligeramente diferente en ciertos contextos, por lo general implica más “anonimato” entre el evento y el evento, que puede ser facilitado por cualquier número de abstracciones, generalmente involucrando a algún “intermediario” (como una cola de mensajes) que lo 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 algún tipo de “notificación de cambio de propiedad” que también contiene información sobre el cambio de propiedad específico. El observador está implícito, generalmente creado por el marco, y se suscribe a estas notificaciones a través de alguna sintaxis vinculante para identificar específicamente un objeto y una propiedad, y el “controlador de eventos” simplemente copia el nuevo valor, lo que potencialmente desencadena 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 uno estúpido:
- se inicia un subproceso en segundo plano que comprueba constantemente la propiedad vinculada en un objeto.
- si ese hilo detecta que el valor de la propiedad ha cambiado desde la última verificación, copie el valor en el elemento vinculado.
Me divierte un poco que todas las respuestas aquí 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 Observador 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 de cualquier cambio de estado.
Patrón de observador
Esto significa un observable object tiene una lista donde guarda todos sus observers(que suelen ser funciones). y puede recorrer esta lista e invocar estas funciones cuando se sienta 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 en consecuencia.
Pero los contras son Los observables solo mantienen una matriz para mantener a los observadores
(en el ejemplo, la matriz es observersList).
NO diferencia 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 los manejadores de observadores en función de diferentes eventos. Solo necesitamos modificar eso observersList a una Object igual que
var events = {
"event1": [handler1, handler2],
"event2": [handler3]
}
vea este ejemplo de pubsub para más detalles.
y la gente llama a esta variación como pub/sub. Para que pueda activar diferentes funciones basadas en el events que publicaste.