Nota: Este capítulo está dedicado al autor de cierto curso fracasado de Ruby on Rails, nuestro estimado Auyama, el Hideki pervertido.
En el capítulo anterior habíamos visto como se estructura una clase, dejando el tema de los eventos para un post aparte. La razón de esto es que el asunto de los eventos requiere una atención especial.
Los eventos son el medio como interactúa una clase con otras o con el propio usuario, se encargan de avisar que algo ha ocurrido y de manejarlo de una forma o de otra. Cada vez que escribimos con nuestro teclado, que hacemos click en un botón o un link, que cambiamos el tamaño de un objeto, estamos generando eventos. Es por ello que, cuando programamos, debemos tener en cuenta la posibilidad (no siempre necesaria, pero lo será a medida que generemos clases cada vez más complejas), tanto de manejar eventos que sólo implican a nuestra clase como de generar nuestros propios eventos, de modo que los usuarios de nuestras clases (en principio nosotros mismos) puedan decidir cómo reaccionará su código ante ellos.
El modo de manejar los eventos en POO se conoce como emisor/receptor, también llamado despachador/escuchador o simplemente dispatcher/listener.
En esta dupla, la primera parte (el emisor) se encargará de lanzar el evento, mientras la segunda se encargará de recibirlo y gestionarlo como sea necesario. La primera parte será responsabilidad nuestra (los programadores de la clase) y la segunda es responsabilidad de quien utiliza la clase (en principio, también nosotros).
Cada lenguaje tiene su propio manejador de eventos, que es el que nos permite, tanto lanzar los eventos como crear los receptores (escuchadores/listeners) que nos permitirán manejarlos. Realmente es una aplicación del patrón Observer, del que hablaremos más adelante, cuando hablemos de patrones, pero que necesariamente tocaremos en este post.
¿En qué consiste la emisión/recepción de eventos?
Básicamente, de lo que se trata es de avisar (en principio sin importar si alguien escucha o no) de algún cambio en el estado de la instancia, que puede ser un click en el objeto, el final de un proceso de carga o la terminación de algún complejo proceso. Cada vez que el evento en cuestión ocurre, la instancia dirá “¡¡Hey, me ocurrió este evento!!”. Esto es lo que conocemos como broadcasting.
Aquí es donde entra en juego el (los) receptor(es). Éste se encargará de estar atento, de escuchar (de ahí que se les llame listeners) el(los) evento(s) que ocurra en el emisor, y responderá adecuadamente.
Para ejecutar esto correctamente, es necesario disponer de una clase que se encargue del manejo de los eventos, tanto de la emisión como de la recepción de los mismos, un eventHandler; ésta puede ser dada por el mismo lenguaje (por ejemplo, el eventDispatcher en AS) o creada por el propio programador.
Información adicional
Si tienes alguna pregunta de este ejemplo; puedes hacerla aqui en los foros.