events - observer - strategy pattern
Diferencia entre el patrón del observador y el enfoque impulsado por eventos (9)
Siempre encontré el patrón de observador casi similar al enfoque habitual orientado a eventos. En realidad, casi he creído que en realidad son solo nombres diferentes que se refieren a lo mismo. Ambos usan conceptos similares para tener algo como un oyente e incluso en la implementación, son casi lo mismo, es decir, tienen un método / función de devolución de llamada para llevar a cabo una acción. Esto es al menos en Java.
En otros idiomas, como Actionscript / Flex, los eventos son más fáciles de usar y pueden parecer más allá de lo que define el patrón del observador. Pero aún así, los conceptos suenan igual.
Pero, ¿es esto realmente cierto? ¿El patrón Observer es lo mismo que el estilo de programación habitual orientado a eventos?
La programación impulsada por eventos es un término para definir un paradigma. mientras que el patrón Observable es una solución de diseño para hacer que una aplicación sea impulsada por eventos.
¡Aclamaciones!
Cuando hay un cambio de estado en el publicador o el sujeto,
Event Driven Architecture (es una arquitectura impulsada por mensajes), responsable de entregar mensajes al Suscriptor, de forma asincrónica.
Patrón de observador (es un patrón de diseño de software), responsable de ordenar al suscriptor que haga algo sincrónicamente.
De la Wikipedia :
El patrón de observador es un patrón de diseño de software en el que un objeto, llamado sujeto, mantiene una lista de sus dependientes, llamados observadores, y los notifica automáticamente sobre cualquier cambio de estado, generalmente llamando a uno de sus métodos.
Se utiliza principalmente para implementar sistemas distribuidos de manejo de eventos, en software "orientado a eventos". La mayoría de los lenguajes modernos como Java y C # han construido construcciones de "eventos" que implementan los componentes del patrón observador, para una programación sencilla y un código corto.
El patrón del observador es un poco más abstracto y teórico. Los eventos son una implementación (comúnmente incorporada), sin embargo, como se señala en la respuesta de Angel, los eventos tienden a poder usarse en algunas otras situaciones, aparte de lo estrictamente definido en el patrón del observador.
He buscado un poco para esta misma pregunta. Para este hilo, encuentro que el punto de Angel O''Sphere en "Qué semántica" y el punto de Spacerat en "Dispatcher" ayudan.
Creo que tengo dos puntos que distinguen a Even-Driver del Observer Pattern. Al menos a partir de la explicación canónica, "Patrón de Observador" usualmente representa una transmisión inmediata una vez que el "Sujeto" ha cambiado y el "Despacho" se implementa llamando a la interfaz proporcionada por el suscriptor o el oyente. Mientras que para Event-Driven, siempre hay otra capa entre "Subject" y "Observer". Se llama "Dispatcher" o usa "Event Queue". Esto proporciona el manejo "retrasado" para reducir el uso de CPU y también proporciona cierta capacidad para llamar a diferentes las interfaces dependen del tipo de evento diferente.
La diferencia básica en ambos es el acoplamiento y el comportamiento sincrónico. Si nos atenemos al patrón del observador, decimos que solo hay una fuente de señal y que sería sincrónico, mientras que por otro lado con los eventos, desacoplamos a ambas partes para que trabajen de forma independiente y al mismo tiempo abriguemos la posibilidad de tener más de una fuente de eventos en el futuro sin ningún cambio de código. Los eventos nos ayudan a adoptar async como diseño. Toda la biblioteca de programación Reactive proporciona un soporte muy bueno para el diseño impulsado por eventos.
La diferencia n. ° 1 puede ser, que los sistemas de eventos siempre tienen un evento que disgrega hilos que desacopla observables de sus observadores para que los eventos no lleguen a los observadores inmediatamente. Mientras que los observables reales llaman directamente a los métodos de observador, los observables dirigidos por eventos dejan caer sus eventos en una secuencia de eventos. Luego, el EDT entrega esos eventos a oyentes registrados.
Lo intento muy simple, porque eso también me ayudó una vez.
Solo piense como Observador y Observable. En lugar de que lo observable marca un conjunto cambiado y el observador solicita de lo observable lo que ha cambiado, lo observable transmite en cambio un objeto (estado llevado por el evento) con toda la información relevante sobre el cambio a los observadores. Entonces, en realidad, hay una instancia más entre el observador y el observable.
http://www.grahambrooks.com/event-driven-architecture/patterns/stateful-event-pattern/
Sí, son principalmente los mismos.
Los eventos son algo así como una plantilla de patrón de observador "incorporada" para algunos idiomas.
Por lo tanto, no implementaría realmente el patrón de observador en un lenguaje que admita eventos ya que proporcionan lo que está buscando.
Por otro lado, puede escribir eventos en idiomas que carecen de eventos utilizando el patrón de observador.
The Observer Pattern es una instancia muy especial. Event-Driven puede significar cualquier cosa. En la mayoría de las implementaciones de Observer Pattern, el Observer es un objeto que observa al observado. Cuando se cambia el observado, se llama un método del observador. Estrictamente hablando, esto no es un "Evento". Eso significa que: varias acciones diferentes en el observado, generalmente conducen a la llamada de diferentes métodos en el observador. La semántica "qué" cambió fue en el método. En Event Driven Systems, básicamente tiene un objeto / método consumidor y el mensaje de lo que se cambió o lo que sucedió en el evento. ¡Eso puede ser cualquier cosa y no se limita a la idea de observar algo! Eso significa que en un Sistema controlado por eventos obtienes nueva semántica agregando nuevos tipos de eventos. En un patrón de observador, normalmente agrega semántica agregando un método a la clase Observer. SIN EMBARGO: nadie le está impidiendo implementar un Observer como línea de aviso especial para ChangeEvents.