Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SCD-1027
"Eventos"
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 P.O.O. 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.
Eventos semánticos:
Eventos de alto nivel que encapsulan la semántica del modelo de
componentes del interfaz de usuario (Hacer una acción, un cambio
de estado en un elemento, etc.). No están relacionados con una
clase específica de componente sino que pueden aplicarse a todos
los componentes que implementen un modelo semántico similar.
Ignorando el evento y permitiendo que pase hacia arriba en el árbol de componentes. Esto es lo
que hace la implementación por defecto de la clase Component. Por ejemplo, como la clase
TextField y su superclase TextComponent no implementan manejadores de eventos, los Campos
de texto obtienen la implementación por defecto de la clase Component. Así cuando un TextField
recibe un evento, lo ignora y permite que su contenedor lo maneje.
Mediante la modificación del ejemplar de Event antes de dejarlo subir por el árbol de componentes.
Por ejemplo, una sublcase de TextField que muestra todas las letras en mayúsculas podría
reaccionar ante la pulsaicón de una letra minúscula cambiando el Event para que contuviera la
versión mayúscula de la letra.
Reacionando de alguna otra forma ante el evento. Por ejemplo, una sublcase de TextField (o un
contenedor de TextField) podrían reaccionar ante la pulsación de la tecla Return llamando a un
método que procese el contenido del campo.
Interceptando el evento, evitando un procesamiento posterior. Por ejemplo, un carácter no válido
se ha introducido en un campo de texto, un manejador de eventos podría parar el evento resultante
y evitar su propagación. Como resultado, la implementación dependiente de la plataforma del
campo de texto nunca vería el evento.
Desde el punto de vista de un Componente, el sistema de manejo de eventos del AWT es como un
sistema de filtrado de eventos. El código dependiente de la plataforma genera un evento, pero los
Componentes tienen una oportunidad para modificar, reaccionar o interceptar el evento antes de
que el código dependiente de la plataforma los procese por completo.
Muchos interfaces EventListener están diseñados para recibir múltiples clases de eventos, por
ejemplo, el interfaz MouseListener puede recibir eventos de pulsación de botón, al soltar el botón, a
la recepción del cursor, etc. El interfaz declara un método para cada uno de estos subtipos. Cuando
se implementa un interfaz, es necesario redefinir todos los métodos que se declaran en ese interfaz,
incluso aunque se haga con métodos vacíos. En la mayoría de las ocasiones, no es necesario
redefinir todos los métodos declarados en el interfaz porque no son útiles para la aplicación.
Por ello, el AWT proporciona un conjunto de clases abstractas adaptadores (Adapter) que coinciden
con las interfaces. Cada clase adaptador implementa un interfaz y redefine todos los métodos
declarados por el interfaz con métodos vacíos, con lo cual se satisface ya el requerimiento de la
redefinición de todos los métodos.