¿Cuál es la diferencia entre Event Listeners & Handlers en Java?

En términos generales de Java, existen oyentes y controladores para eventos.
Quiero decir que los uso sin saberlo, solo el que esté disponible en la API.

Mi pregunta es, ¿en qué caso usamos oyentes y en qué caso usamos controladores para eventos?

¿Cual es la diferencia entre ellos? Caracteristicas ??

He buscado razones y no pude encontrar una explicación adecuada para Java.

No existe una diferencia definida formalmente entre oyentes y manipuladores. Algunas personas probablemente argumentarían que son intercambiables. Para mí, sin embargo, tienen un significado ligeramente diferente.

Un oyente es un objeto que se suscribe a eventos de una fuente. Cf. el patrón del observador . Por lo general, puede tener muchos oyentes que se suscriban para cada tipo de evento, y se agregan mediante addXyzListenermétodos.

Ejemplo: El MouseListeneren el API Java.

Un controlador es un objeto que se encarga de manejar ciertos eventos. Un escenario típico sería proporcionar un controlador para un evento / tarea específico como argumento para un constructor, o configurar el controlador a través de un setXyzHandlermétodo. En otras palabras, normalmente tiene un controlador para cada tipo de evento.

Ejemplo: El MemoryHandleren el API Java.

La diferencia más básica es la asociación

• El oyente está asociado con el origen del evento (p. Ej., Teclado)
• El controlador está asociado con un evento (p. Ej., Keydown)

En términos generales, solo habrá un Handler Manager central que gestione todos los eventos, mientras que en el caso de Listener cada Entidad que quiera escuchar, tendrá que gestionar su propia Colección de oyentes.

Esta es la forma en que lo veo:

Un oyente espera que se dispare un evento. Por ejemplo, a KeyListenerespera a KeyEvents, a MessageListenerespera a que los mensajes lleguen a una cola y así sucesivamente.

El manejador es responsable de lidiar con el evento. Normalmente, los oyentes y los manipuladores van de la mano. Por ejemplo, KeyListener le dice a ExitHandler que "se presionó la letra Q" y el controlador realiza la lógica, como limpiar los recursos y salir de la aplicación sin problemas. De manera similar, un ButtonClickListener le diría al mismo ExitHandler que se hizo clic en el "botón Salir". Entonces, en este caso, tiene dos eventos diferentes, dos oyentes diferentes pero un solo controlador.

Un oyente es un objeto al que se le notifica cuando ocurre un evento y tiene 2 requisitos principales: 1: debe haberse registrado con una o más fuentes para recibir notificaciones sobre tipos específicos de eventos 2: debe implementar métodos para recibir y procesar estas notificaciones. Handler es responsable de lidiar con los eventos.

Un oyente escucha eventos que son objetos de valor de datos que describen un evento. Cuándo ocurrió el evento y el orden de los eventos es a menudo importante. Presionar la tecla '0' seguida de '1' es diferente a '1' y '0'.

Un controlador, maneja un objeto complejo, por ejemplo, una nueva conexión Socket. El controlador puede procesar el objeto durante cualquier período de tiempo. El momento de la creación y el orden de los objetos no es tan importante. Una conexión de client0 o client1 puede ocurrir en cualquier orden.

Creo que la diferencia es sutil porque un Oyente concreto también es un controlador de eventos o al menos tiene un método que puede considerarse un controlador de eventos. Es decir, un Oyente concreto maneja o administra la reacción al evento después de recibir un objeto de evento (de la fuente del evento) con toda la información útil sobre el evento que acaba de ocurrir (en la fuente del evento). Como este Listener tiene que implementar una interfaz xxxListener que lo obliga a implementar al menos un método que a su vez es ejecutado por el objeto fuente del evento cuando ocurre el evento, el Listener en sí mismo puede considerarse un controlador y, más precisamente, el método la interfaz Listener implementada por el objeto Listener puede considerarse el controlador de eventos real. Entonces, veo el controlador de eventos como solo el código que se ejecuta en reacción a un evento. Esto es diferente de un objeto Listener que es un elemento de un concepto más abstracto, como un patrón de diseño Observer. Esta es mi visión personal del tema.

En mi opinión, la diferencia más importante es el hecho de que usamos oyentes por fuente de evento, a diferencia del controlador, que es por tipo de evento.

Son conceptualmente lo mismo: un objeto que realiza alguna acción en respuesta a un evento de IU. Generalmente, en Swing, estos objetos se denominan "controladores" en el nivel de apariencia (para manejar eventos de widget de bajo nivel) y "oyentes" en el nivel de interfaz de usuario más abstracto (donde implementará la lógica de su aplicación ).

EventHandler se introduce en JavaFX para todos los controles de la interfaz de usuario. Mientras que el Listener se toma prestado para Observables, como propiedades.

EventHandler es una forma de distinguir eventos observables y eventos de interfaz de usuario.

He estado tratando de darle sentido a toda la información y estoy perdido. He mirado a Delphi (Pascal), C, C ++, java ... nada está claro, así que después de un mes, este es el problema tal como lo veo. Puede que esté totalmente fuera de lugar, así que por favor dígame ... cortésmente, por favor.

Un remitente de evento, un receptor, siempre que el remitente registre al receptor. Tengo 4 cuadros de diálogo que deben actualizarse cada vez que cambia un archivo (cuyo código de manejo está en otro módulo que los 4 cuadros de diálogo). Consideré actualizar cada uno a la antigua, pero luego miré los eventos de Delphi y el manejo de mensajes. Veamos:

El archivo F (el remitente) ha terminado de leerse y debería notificar a los diálogos 1..4 del hecho de que ahora hay datos para que los muestren y el usuario pueda jugar con ellos. ¿Qué es lo mejor?

¿Intentar registrar los Diálogos 1..4 como oyentes y hacer que el remitente active un OnUpdatedDataEvent de alguna manera?

Intente enviar un mensaje a través del sistema, con la esperanza de que Dialogs 1..4 lo capte.

Tenga en cuenta que el evento mantiene las cosas acopladas, mientras que los mensajes no ... y son difíciles de depurar.

Y me pregunto cómo el bloque de código Archivo podrá registrar 4 oyentes (los cuadros de diálogo).

Lo que estoy viendo es la posibilidad de llamadas en cascada, lo que significa que la persona que llama llama a un oyente, quien llama al siguiente ... hasta que llega al final de la cadena. Incluso me pregunto si eso es posible.

Un ejemplo:

Decir Archivo F es una lista de idiomas. Ahora, DialogBox 1 hace algo en la lista (agrega un nuevo idioma, por ejemplo); ese cuadro combinado actualiza el archivo F; esto, a su vez, desencadena un DataUpdatedEvent. los 4 cuadros de diálogo contienen, digamos, TComboBoxes que muestran la lista de idiomas cuando aparecen. Quiero que los 4 cuadros noten el cambio y actualicen el contenido del cuadro combinado con el archivo recién actualizado ... sin tener que preocuparme por cómo saben los cuadros combinados que necesitan actualizar su contenido. Si funciona según lo previsto, el parámetro Sender se trasladará y el cuadro de diálogo que desencadenó el evento dataUpdateEvent se omitirá porque ya se actualizará. Después de todo, un if sender = self luego continuar con el siguiente controlador de eventos debería ser fácil de implementar.

Todo eso porque quiero ejercitar mi cerebro ... para prevenir el Alzheimer, no con mucho éxito, podría agregar.

Es semántica.

• El oyente es interfaz.
• El adaptador es una clase que implementa una interfaz específica y proporciona una implementación vacía para sus métodos. Esto ayuda si no tiene que implementar todos los métodos de interfaz.
• Handler implementa varias interfaces o delega llamadas a varias interfaces.