Se solicita información sobre el paradero del estudiante Arshak Karhanyan

Clase 8

Viernes (Noche, 2024)

¡Hola todo el mundo!

Dr Nick

Resumen

En esta clase aprendimos sobre la noción de eventos para comunicar cosas que ocurren en nuestro sistema a otros objetos, sin acoplarnos a lo que hacen, pero ganando en flexibilidad de que se puedan suscribir otros interesados:

Trabajamos sobre conceptos tales como:

  • evento: cualquier cosa que acontece (sí, es una definición muy genérica)
  • sujeto observable (o simplemente, sujeto, o simplemente observable): aquel ente que es la fuente de eventos y es capaz de producir notificacionesa
  • notifación: el mensaje que se envía desde el sujeto observable a un observador, ante la ocurrencia de un cierto evento
  • observador: el ente interesando en los eventos de un sujeto observable
  • suscripción: el acto por el cual el observador expresa su interés en (uno o alguno de) los eventos que le suceden al observable.

  • acción: aquello que un observador realiza ante la ocurrencia de un evento para el que está suscripto Comentamos que, dependiendo de la tecnología, la literatura y la implementación de esta noción, existen muchos sinónimos para algunos de estos conceptos:

  • listener, subscriber (suscriptor) como sinónimos de observer (observador)
  • listen,subscribe, register, todos verbos que funcionan como cuasi-sinónimos de la acción de crear una suscripción
  • reacción: dado que las acciones de las que hablamos son en respuesta a un evento, es común referirlas como reacciones (de donde viene un sinónimo del diseño orientado a eventos: el diseño reactivo)

Dado que virtualmente cualquier operación en un sistema puede ser pensada como un evento, nos resulta útil acotar su uso a ciertos escenarios en que:

  • existan múltiples potenciales formas de reaccionar ante esos eventos
  • en que esta o estas potenciales formas de reaccionar sean configurables en tiempo de ejecución (es decir, que en un instante t0 se reaccione de una forma, y en otro instante t1 se reemplace esa forma de reaccionar por otra, o incluso se ignore el evento)
  • pueda existir, al mismo tiempo, más de una forma de reaccionar, ocasionando que un evento desencadene cero o más acciones
  • que las acciones sean mayormente independientes entre sí (esto se estudiará en mas detalle en la siguiente clase)
  • en suma, que no exista un vínculo rígido entre los eventos y sus reacciones (o lo que es casi lo mismo, entre los observables y sus observadores) y que por tanto, busquemos desacoplar los primeros de los segundos.

Los eventos, en un sentido de cualidades de diseño, son algo chiquito, pero sirve para cosas muy poderosas/heavies como recopilar datos, analytics, trazabilidad, explotación de datos y extractivismo digital, vigilancia, inversión de control, o simplemente desacoplamiento.

Luego, trabajamos en particular una posible implementación de la noción de eventos en la programación con objetos: el patrón observer. En este patrón…

que no es la única forma, existen otras formas de implementar eventos, como callbacks, reactores, programación reactiva, etc

…se cumple que:

  • el observable notifica uno o más tipos de eventos diferentes
  • estos eventos podrían notificarse muchas veces, una vez, o incluso ninguna
  • el observable se caracteriza por exponer mensajes que permiten la suscripción de observadores, que típicamente siguen algún patrón de nombres del estilo:
    • Cuando el observable produce un único tipo de evento o existe una única interfaz que lo observa: agregarSuscriptor / agregarObservador / registrarSuscriptor / addListener / etc
    • Cuando el observable produce múltiples tipos de eventos o existen múltiples interfaces que lo observan:
      • agregarSuscriptorDe${EventoX} / agregarObservadorDe${EventoX} / registrarSuscriptorDe${EventoX} / add${EventoX}Listener / etc
      • on${EventoX} / ante${EventoX}: un poco menos evidente, pero igualmente común
  • el observador se caracteriza por entender un mensaje manejador (handler) por cada tipo de evento ante el cual puede reaccionar. En general, estos métodos deben tener void por retorno, es decir, no deben retornar nada. Acá nuevamente existen diferentes convenciones:
    • run / call / execute / etc: no es lo más común (dado que son nombre con una semántica más próxima a una cosificación de comportamiento), pero en ocasiones puede verse de esa forma si el observador sólo soporta un tipo de evento
    • notify / notify${EventoX}: semánticamente más correcto y un poco más frecuente (de hecho, así se puede encontrar en varias ediciones del catálogo de patrones GOF)
    • nuevamente on${EventoX} / ante${EventoX}. Esta forma es bastante común también, aunque a diferente del item anterior, en que se usaban para registrar observadores, acá tendrán otra firma: recibirán la notificación en lugar del observador.

Esto nos arroja cuatro corolarios:

  • No existe una interfaz bien definida y genérica para los observables; lo que los hace observables es justamente su capacidad de registrar observadores.
  • Normalmente, existirá una implementación de observador para cada acción posible.
  • Normalmente, existirá una interfaz observadora por cada tipo de evento posible.
  • Normalmente, existirá un método para registrar un observador por cada tipo de evento posible.

Material utilizado

Práctica

Material complementario

Para la próxima clase 📅