Actualmente estoy siguiendo una clase sobre Patrones de diseño y me preguntaba si un EventListener es un Observable?¿Es un EventListener un observable?
Realmente no veo una diferencia entre ellos porque ambos tienen una lista de suscriptores y notifican a estos suscriptores cuando algo ha cambiado.
Un Observable es simplemente un objeto donde puede observar sus acciones. Entonces, cualquier cosa donde pueda escuchar una acción y luego se le diga que ocurre una acción es un Observable.
Esto significa que un Oyente de eventos es uno. Porque puedes escuchar los eventos y los eventos inmediatamente te notifican que han sucedido.
Personalmente cuando alguien dice Observable Creo que los eventos. Este es mi ejemplo de cortador de galletas de lo que son los observables. Un ejemplo similar sería un sistema de publicación y suscripción que es solo eventos con un nombre diferente (tiene un caso de uso sutilmente diferente).
Sí, parece que una cola de eventos donde registrar oyentes para eventos específicos sería un ejemplo de un patrón de observador.
También investigué un poco más investigando el código fuente de JDK. Creo que la única diferencia entre ellos es que un Observable usa sincronizado al agregar Observers y un EventListener no (al menos AbstractButton no).
Según mi experiencia, un patrón de Escucha de eventos es algo diferente de Observer Design Pattern. No es solo un nombre diferente o que es parte de eso.
Tengo que hablar de esto concretamente. Por ejemplo, este page proporciona una implementación C# de un sistema de escucha de eventos. En este sistema, un oyente registra su función de manejo de eventos con una clase singleton Events y afirma que puede manejar un tipo particular de evento. Events mantiene un diccionario para asignar cada tipo de evento a su función de controlador. Por otro lado, cualquier clase que quiera activar el evento debe hacerlo a través de la función de singleton Events.instance.Raise().
Aquí podemos ver 3 diferencias:
En primer lugar el propósito de los dos patrones son diferentes: Oyente El diseño está para desacoplar la detección de eventos/elevar código a partir del código de manejo de eventos, por lo que cuando cambiar o agregar nuevos códigos de manejo de eventos, no afecta a otros códigos de manejo de eventos; El patrón de diseño del observador consiste en hacer que algunos objetos sigan los cambios de otro objeto.
La estructura de datos también es diferente. En Listener Design Pattern, solo hay un diccionario global para asignar cada tipo de evento a su método de manejo. Este mapeo es de 1 a 1. Mientras se encuentra en el patrón del observador, cada sujeto observado mantiene una lista de observadores. Este mapeo es de 1 a muchos: uno sujeto a muchos observadores. Puede haber múltiples instancias de tales relaciones de sujeto a observador de 1 a muchos.
El comportamiento es diferente. En Listener Design Pattern, cuando ocurre un evento, el evento notifica a un mediador global (el singleton Events.instance), porque no tiene información sobre los manejadores de eventos. Mientras se encuentra en el patrón observador, cuando ocurre algún cambio, el sujeto observado notifica directamente a todos los observadores.
Yo diría que un oyente de eventos es un observador, ¿no? –
[Patrón de diseño del observador frente a "Oyentes"] (https://stackoverflow.com/questions/3358622/) – sepehr