Programación

Orientada a Eventos

Landero, P (2021). Programación Orientada

a Eventos [apunte]. Chile. UNAB
Programación orientada a eventos

1. INTRODUCCIÓN Pág. 2

2. PROGRAMACIÓN ORIENTADA A EVENTOS (POE) Pág. 4

2.1. Conceptos de POO y comparación con otros paradigmas.

• Comparación con la programación estructurada.
• Conceptos principales de la POE
• Ejemplo de creación de una guía simple para relacionarla con la POO

2.2. Componentes GUI de Java.

• Componenetes
• Contenedores
• Gestores de Esquemas

3. GESTIÓN EVENTOS USANDO PATRÓN DE DISEÑO OBSERVADOR

–OBSERVABLE Pág.18

4.GESTIÓN EVENTOS USANDO PATRÓN DE DISEÑO MODELO VISTA

CONTROLADOR (MVC). Pág. 26

5. CASO PROPUESTO Pág. 28

1
Programación orientada a eventos

1. INTRODUCCIÓN

El propósito de este apunte es entregar al estudiante los conceptos más relevantes

de la Programación Orientada a Eventos (POE) y conectar estos conocimientos con
los entregados en las unidades anteriores. Te invito a aplicar lo que aprenderás en
este capítulo desarrollando el desafío propuesto al final de este documento y si
necesitas profundizar en algún contenido, puedes consultar el libro (capítulo 21)
Joyanes, A. L., Zahonero, M. I. (2011). Programación en Java: algoritmos y
programación orientada a objetos.

En las unidades anteriores aprendimos y aplicamos los principios de abstracción,

encapsulamiento, herencia y polimorfismo de la POO. Construimos un modelado de
clases a través de la identificación de los objetos en función de sus datos y
comportamientos. En esta unidad aplicaremos la Programación Orientada a Eventos
(POE) con el uso de componentes de Interfaz Gráfica de Usuarios (GUI) donde
se presentarán al usuario pantallas o vistas que, con la interacción de estos
componentes (botones, listas, etc.), generarán los eventos que el programa, a través
de sus métodos controladores, gestionará para decidir e invocar los comportamientos
del modelo definido.

Figura 1.1 2
Diagrama de conocimientos e integración de la POO y POE de este curso.
Programación orientada a eventos

Primero, en este apunte, entregaremos los conceptos de la POE y las diferencias con
otros paradigmas, especialmente con la POO. A continuación, implementaremos la
interfaz de usuario como una componente que alberga una serie de componentes
visuales presentados al usuario. Es necesario que conozcas las más importantes para
que puedas implementar tus propias GUI. Finalmente, revisaremos cómo se integran
estas componentes GUI con el modelo de clases a través de los controladores de
gestión de eventos.

3
Programación orientada a eventos

2. PROGRAMACIÓN ORIENTADA A EVENTOS (POE)

2.1. Conceptos de POO y comparación con otros paradigmas

COMPARACIÓN CON LA PROGRAMACIÓN ESTRUCTURADA:

En contraposición al modelo clásico, la programación orientada a eventos

permite interactuar con el usuario en cualquier momento de la ejecución. Esto se
consigue debido a que los programas creados bajo esta arquitectura se componen
por un bucle exterior permanente encargado de recoger los eventos, y distintos
procesos (o métodos) que se encargan de tratarlos. Habitualmente, este bucle
externo permanece oculto al programador que simplemente se encarga de tratar los
eventos, aunque en algunos entornos de desarrollo (IDE) será necesaria su
construcción.

A continuación, se realiza una comparación sencilla entre el paradigma estructurado

versus el orientado a eventos.

Indicador de Programación Secuencial Programación dirigida por

comparación (estructurada) eventos
Flujo de ejecución del el programador es quien el usuario u otro agente
programa. define cuál será el flujo del externo que esté accionando
4
programa. el programa es quien dirigirá
El programador decide el el flujo del programa.
orden de ejecución de los Escapa al control del
procesos. programador.

Entradas o las intervenciones de un Las intervenciones de un

intervenciones desde agente externo ocurrirán agente externo pueden
un agente externo. cuando el programador lo ocurrir en cualquier momento.
haya determinado.
Control de Errores de la naturaleza indeterminada Para programas que se
ejecución del de las acciones del usuario y requieren pasos ordenados y
programa. las características de este específicos de las
paradigma pueden interacciones del usuario es
desembocar en errores más fácil predecir y encontrar
graves. errores de ejecución.

En este apunte apicararemos la POE usando interfaces de usuarios y revisaremos

cómo se conecta esta componente de interacción con la POO. Te darás cuenta de que
la POE está más asociada a cómo gestionar (o controlar) los eventos, para ejecutar
los comportamientos apropiados, que un cambio de paradigma; ya que el concepto
fundamental de la POO se sigue manteniendo. Por eso, la POE es una consecuencia
o una derivación de la misma POO. Para que comprendas esto, primero vamos a
Programación orientada a eventos

definir algunos de los conceptos principales de POE y luego los relacionaremos con lo
que has aprendido en POO usando un ejemplo específico.

CONCEPTOS PRINCIPALES DE LA POE:

• Eventos. En simples palabras, un evento es una acción que es reconocida por

una componente GUI y que normalmente es provocada por el usuario al
interactuar con la Interfaz (vista) del programa. Pulsar una tecla, hacer clic
sobre un botón, arrastrar el ícono del mouse, entre otros, son ejemplos de
eventos.
• Propiedad: son atributos que describen las componentes de una interfaz
de usuario. La componente botón del ejemplo anterior se le puede asignar las
propiedades: Nombre (Name), Ancho (Whidth), Alto (Heigth), etc.
• Métodos: como ya lo sabes, son los comportamientos o funciones codificadas
por el programador que se ejecutan cuando se producen los eventos.
• Controlador (o gestor) de eventos: es un conjunto de métodos que
reciben la información del evento generado por el usuario para decidir el o los
comportamientos que se deben ejecutar para responder con el requerimiento.

5
EJEMPLO DE CREACIÓN DE UNA GUI SIMPLE PARA RELACIONARLA CON LA
POO

La figura 2.1 es un ejemplo simple de una pantalla (o formulario) para que el usuario
interactúe ingresando números que se van acumulando y mostrando el resultado en
el campo donde dice total.

Figura 2.1
Ejemplo de un objeto formulario o ventana de interacción con el usuario.
Programación orientada a eventos

Bueno, tienes que saber que esta pantalla es un objeto que fue instanciado por una
clase creada por nosotros (que la llamaremos VistaSumadorImp), donde sus
atributos y su constructor se definieron de la siguiente forma:

6
Los atributos (o componentes botonSumar, txtValor, etc.) de esta clase son
también objetos que referencian a otras clases que ya se encuentran definidas en
una biblioteca de Java para trabajar con ellas. Las clases que están referenciando
estos atributos son:
• JButton
• JTextField
• JLabel

Por lo tanto, estas componentes que referencian a dichas clases pueden usar todos
los métodos que se encuentran definidos en la biblioteca Java y que te servirán para
darle a tu pantalla el aspecto y la funcionalidad requerida. Entonces, para el ejemplo
podemos definir un diagrama de clases como el siguiente:
Programación orientada a eventos

Figura 2.3
Diagrama de Clases para implementar el ejemplo de la figura 2.1.

Ya sabes que la clase Acumulador se implementa de la siguiente forma:

El main que se implementó en la clase PrincipalAcumulador quedaría como lo

siguiente:
Programación orientada a eventos

Figura 2.4
Programa main para crear y generar aspectos visuales del ejemplo

Los objetos vista y acum se crean como lo hemos aprendido hasta ahora, solo debes
tener cuidado de crear un objeto JFrame para alojar allí nuestra pantalla. Recuerda
que al crear el objeto vista de la clase VistaSumadorImp, este constructor también
crea los objetos botonSumar, txtTotal, txtValor, etc. por la relación compuesta que
existe entre ellos. El método crearGUI permite dar el aspecto requerido a mi pantalla
gracias a la API que nos provee Java a través de los objetos que hemos creado
(ventana, botonSumar, txtValor, etc.).
8
Te dejo la programación de la clase VistaSumadorImpl para que veas cómo se
implementó el método crearGUI y conozcas las clases que se importaron de la API
con la ejecución de algunos de sus métodos.
Programación orientada a eventos

Figura 2.5
Programa de la clase VistaSumadorImpl del ejemplo 2.1.

La estructura de las clases de nuestra implementación, así como te lo comento en el

main, es la siguiente:
Programación orientada a eventos

Figura 2.6
Estructura de Clases para el ejemplo de la figura 2.1.

Por lo tanto, al ejecutar el main la salida es la siguiente:

Figura 2.7
Salida al ejecutar el programa main de la figura 2.4

10

Hasta aquí solo hemos programado la creación de la pantalla y su aspecto visual. Al

presionar el botón “Sumar” no hará nada. Lo que falta es definir una clase para
programar los métodos que controlan los eventos generados por el usuario (al
interactuar con la interfaz), en este ejemplo, el evento que se ha de controlar es
cuando el usuario presione el botón “Sumar”, donde el programa debe actualizar el
atributo total de la clase Acumulador y mostrar el nuevo total. Esto lo aprenderemos
en el apartado 2.3 de este apunte.

Si te das cuenta, el concepto central de la POO se mantiene. Solo debemos conocer

cuáles son todos los componentes (al menos los más importantes) que se pueden
definir en las pantallas de usuarios para que él pueda interactuar de una manera
simple y amigable. Esto es lo que veremos a continuación.
Programación orientada a eventos

2.2. Componentes GUI de Java

AWT (Abstract Windows Toolkit) es la parte de Java que se emplea para construir
interfaces gráficas de usuario. Este paquete ha estado presente desde la primera
versión, en la versión 1.2 se incorporó una librería adicional, JFC Swing, que
enriquece a AWT en la construcción de aplicaciones gráficas. No hay mucha diferencia
en la estructura entre los controles proporcionados por AWT y los proporcionados por
Swing. Estos se llaman, en general, igual que los primeros, salvo que tienen una "J"
delante; así, por ejemplo, la clase Button de AWT pasa a llamarse JButton en Swing,
y en general la estructura del paquete de Swing (javax.swing) es la misma que la
que tiene AWT (java.awt).

La estructura básica de la biblioteca gira en torno a los conceptos componentes y

contenedores.

Componentes:
Los componentes son los elementos visuales de una GUI. Considere lo siguiente:
• Cada elemento gráfico de GUI es un componente.
• Cada componente es una instancia (un objeto) de una clase.
• Un componente se crea como cualquier otro objeto Java.
• Botones (JButton), etiquetas (JLabel), campos de texto (JTextField), son
ejemplos y componentes. 11
• Se sitúan dentro de algún contenedor (componente especializado).

Contenedores:

Los contenedores contienen componentes y son componentes a su vez, cuya finalidad

principal es la de organizar componentes. Considere lo siguiente:
• Los contenedores pueden contener componentes y otros contenedores.
• Todo componente GUI debe formar parte de la jerarquía de contenedores.
• A cada contenedor se le establece un layout. Un layout establece la
disposición de los componentes dentro del contenedor. Los componentes se
añaden a un contenedor con el método add.
• Los contenedores pueden ser de dos tipos:
• Contenedores de alto nivel (o superiores): forman la base para
realizar una GUI (JApplet, JFrame y JDialog).
• Contienen un panel de contenidos (ContentPane) donde usualmente se
coloca la vista.
• Pueden contener opcionalmente una barra de menú (MenuBar).
• La jerarquía de clases de contenedores superiores es la siguiente:
Programación orientada a eventos

Figura 2.8
Jerarquía de contenedores superiores de AWT y Java Swing para interfaces
gráficas.

12
a) Contenedores intermedios: almacenan componentes y contenedores
intermedios (JPanel, JScrollPane, JSplitPane, JTabbedPane, etc.).
• permiten organizar la estructura y composición de las vistas.
• Contienen a los componentes y a otros contenedores, permitiendo
construir jerarquías de componentes.
• La jerarquía de clases de contenedores intermedios es la siguiente:
Programación orientada a eventos

Figura 2.9
Jerarquía de contenedores intermedios AWT y Java Swing para interfaces gráfica.

- El contenedor intermedio más utilizado es javax.swing.JPanel.

Permite añadir múltiples componentes y contenedores intermedios al
panel, que serán organizados según un determinado gestor de
esquemas. El gestor de esquemas por defecto del contenedor JPanel
es FlowLayout (ver definición más adelante). 13

Jerarquía de Componentes que no son contenedores (JComponent):

Figura 2.10
Jerarquía de componentes Java Swing NO contenedores para interfaces gráfica.
Programación orientada a eventos

Lo que usamos en nuestro ejemplo de la figura 2.1 fue la siguiente disposición de

componentes:

Figura 2.11
Ejemplo de disposición de componentes para una interfaz de usuario

Aspecto visual de algunos Componentes que no son contenedores (JComponent):

14
Figura 2.12
Ejemplos de Aspecto visual de algunos Componentes Swing que no son contenedores.
Programación orientada a eventos

Otras clases que te ayudarán a distribuir los componentes de la interfaz de usuario

son los Gestores de Esquemas.

Gestores de Esquemas:

Los gestores de esquemas son clases que determinan cómo se distribuirán los
componentes dentro de un contenedor intermedio. La mayoría de los gestores de
esquemas están definidos en java.awt. Algunos son:
• FlowLayout: organiza los componentes según un flujo direccional. Con el
gestor de esquemas java.awt.FlowLayout, los componentes fluyen de
izquierda a derecha y de arriba a abajo. Al cambiar el tamaño de la ventana,
puede cambiar la disposición de los componentes.

15
• BoxLayout: organiza los componentes horizontalmente o verticalmente. Con
el gestor de esquemas java.awt.BoxLayout, los componentes se distribuyen
horizontal o verticalmente.

• Al cambiar el tamaño de la ventana, se redimensionan los componentes.

• El constructor debe especificar el panel donde reside, y la orientación de
los componentes (BoxLayout.X_AXIS, BoxLayout.Y_AXIS).
• Proporciona el siguiente constructor
BoxLayout(Container, int); // crea el gestor de esquemas
Programación orientada a eventos

• BorderLayout: organiza los componentes alrededor de uno central. Con el

gestor de esquemas java.awt.BorderLayout, el contenedor se divide en 5
zonas: NORTH, WEST, CENTER, EAST, SOUTH.
• Los componentes ajustan su tamaño hasta rellenar completamente cada
zona.
• Si falta algún componente, entonces su zona se ajusta con el resto.
• Para añadir un componente al contenedor, se utiliza una versión de add
que indica la zona en la que se añade (BorderLayout.NORTH,
BorderLayout.WEST, BorderLayout.CENTER, BorderLayout.EAST,
BorderLayout.SOUTH).
add(boton, BorderLayout.NORTH);

16
• GridLayout: organiza los componentes según una cuadrícula. Con el gestor
de esquemas java.awt.GridLayout, el contenedor se divide en una cuadrícula
con tantas filas y columnas como se especifique en el constructor.
setLayout(new GridLayout(2, 3)); // Dos filas y tres columnas
• Los componentes se mantienen de igual tamaño dentro de cada celda.
• El orden a la hora de agregar los componentes determina la posición
que ocupan (de izquierda a derecha y de arriba a abajo).

Revisa el capítulo 21 libro del curso Joyanes, A. L., Zahonero, M. I. (2011).

Programación en Java: algoritmos y programación orientada a objetos. En este
capítulo aparecen varios ejemplos para que ya empieces a programar por tu cuenta
y sigas aprendiendo.
Programación orientada a eventos

Recuerda que revisamos los componentes, ya que a través de estos (con la

interacción del usuario), se generan eventos que serán gestionados por los
controladores de eventos utilizando algún patrón conocido y que, obviamente, esté
comprobado que funciona correctamente. Esto es lo que veremos en los siguientes
dos apartados.

17
Programación orientada a eventos

3. GESTIÓN EVENTOS USANDO PATRÓN OBSERVADOR – OBSERVABLE

Cuando programamos interfaces gráficas de usuario, los distintos componentes de la

interfaz son observables y escribiremos métodos observadores en una clase
Observadora (Listener en Java) que serán notificadas cada vez que el usuario
interaccione con un componente de la interfaz. Es decir, estos métodos que se
escriben en una clase Listener (observadora o escuchadora) se ejecutan cuando
sean notificados a través de un evento producido por el usuario.

Figura 3.1
Representación Escuchador ejecuta comportamientos en función del evento notificado.

18

En la figura siguiente 3.2, se representa la gestión de eventos de Java usando el

patrón observador – observable.
Programación orientada a eventos

Figura 3.2
Gestión Eventos Java usando patrón de diseño Observador (Listener) – Observable (Source)

Debes considerar lo siguiente:

1. Para cada componente (con el que interaccione el usuario) debes elegir el

escuchador (Listener) adecuado para controlar el evento asociado al
componente. Por ejemplo, el evento ActionEvent se dispara si:
19
• Se pulsa un botón de cualquier tipo.
• Se selecciona una opción de menú.
• Se pulsa retorno de carro en un campo de texto.

Por lo tanto, la clase de eventos que debes importar para este caso es
javax.swing.event.ActionEvent y el escuchador que debes elegir para
programar es la interfaz ActionListener. El nombre de la clase de un evento
tiene el formato XxxxxEvent (según el tipo de evento), lo mismo sucede con el
nombre de la interfaz del escuchador que tiene formato XxxxxListener.

Para conocer los eventos que lanzan las distintas componentes puedes consultar:
https://docs.oracle.com/javase/tutorial/uiswing/events/eventsandcomponents.h
tml
Programación orientada a eventos

Al final de este apartado te dejo la jerarquía de los principales eventos con su

respectiva clase controladora y los métodos que se deben implementar
dependiendo de la situación.

2. Una vez identificada la interfaz relacionada con el evento, estamos obligados a

implementar los métodos de los controladores correspondientes. En nuestro
ejemplo, el evento es ActionEvent y la interfaz escuchadora es
ActionListener, entonces el método que debes implementar (según la tabla de
arriba) es actionPerformed:

Sobre el objeto evento, se puede invocar al método getActionCommand() para

conocer su identificador asociado, que fue previamente establecido. El ejemplo
quedaría así:

20
Programación orientada a eventos

3. Finalmente, debemos registrar los controladores para poder identificar los

cambios que se generen en las componentes con las que interactúa el usuario.
Para registrar un controlador a la escuchadora de eventos disparados por un
componente, se debe invocar al método adecuado (según el tipo de evento,
addXxxxxListener()) sobre el componente que emite el evento, indicando a la
escuchadora cuál es el controlador. Por ejemplo:

componente.addActionListener(controlador);

Entonces el nuevo diagrama de clases que debemos implementar para el problema

de la figura 2.1 corresponde al de la figura 3.3. A diferencia del que hicimos en el
apartado anterior (figura 2.3) hemos agregado la interfaz ActionListener y la clase
que la implementa (Escuchadora) con esto cubrimos las consideraciones 1) y 2);
faltaría registrar los controladores, estos se registran en la vista de implementación 21
de nuestra pantalla, quedando como sigue:

Figura 3.3
Diseño ejercicio figura 2.1 usando patrón de diseño Observador– Observable
Programación orientada a eventos

La implementación de la clase escuchadora queda como se muestra:

A la implementación de clase VistaSumadorImpl (figura 2.5) se agregue lo

siguiente: 22
Programación orientada a eventos

Finalmente, el main queda de la siguiente forma:

Por lo tanto, la dificultad respecto a lo que has aprendido hasta ahora es identificar
correctamente el evento para poder programar el método correspondiente. Te dejo
los principales para que los vayas conociendo.

Figura 3.4
Jerarquía de eventos asociados a componentes GUI Java.

23
Programación orientada a eventos

Sabemos que cada objeto (observable) genera un tipo específico de evento que debe
ser representada con su clase adecuada.

Son clases que deben representar los tipos de eventos que escuchan, estas clases
deben implementar una o varias interfaces para ejecutar métodos de acuerdo al tipo
de evento.

24

Sin embargo, la mayoría de interfaces tienen más de un método que tal vez no debas
usar. Debido a este motivo han creado una serie de clases adaptadoras encargadas
de cumplir la misma función, pero la ventaja es que solo usas los métodos que
necesites (son clases que ya implementan las interfaces mencionadas anteriormente
y estas también se utilizan para crear oyentes).
Programación orientada a eventos

Los eventos permiten incrementar la funcionalidad del programa, permitiendo al

usuario interactuar de manera fácil. Pues como desarrollador, puedes hacer que un
botón, por ejemplo, cambie el color de fondo o ejecute funciones más complejas. En
este artículo solo doy una breve introducción, en futuros artículos explicaré cómo
implementar los diferentes tipos de eventos.

25
Programación orientada a eventos

4. GESTIÓN EVENTOS USANDO PATRÓN MODELO VISTA CONTROLADOR

La idea básica de este patrón es agrupar las clases según tres roles:
• Modelo: este rol lo juegan todas las clases responsables de mantener y
gestionar los datos de nuestra aplicación.
• Vista: este rol lo juegan todas las clases responsables de visualizar datos.
• Controlador: conecta la Vista con el Modelo. También conectado con la
dinámica de la aplicación.

Figura 4.1
Interacción entre las componentes Modelo, Vista y Controlador del patrón MVC

26

Imagina que estás desarrollando una aplicación para gestionar tus gastos.
• La Vista es la responsable de mostrar la información gráficamente.
• El Modelo mantiene los datos de tus gastos.
• El Controlador realiza cambios en el Modelo cuando el usuario interacciona
con la Vista.

Ventajas:
• La principal ventaja de este patrón es que se ha desacoplado el modelo de
datos y su visualización.
• Puedo cambiar el aspecto de la Vista sin necesidad de modificar el Modelo.
Ejemplo: si tenemos una aplicación que muestra los datos del Modelo en
forma de gráfico de dos dimensiones, podríamos reemplazar el gráfico, o
añadir, además, una visualización de los datos en una tabla. Puedo, incluso,
tener más de una Vista del mismo Modelo.
• Puedo cambiar el Modelo sin modificar la Vista. Los datos de
mi Modelo pueden estar en un simple fichero de texto, pero en el momento
en que necesite utilizar una BD, cambiaré solo el Modelo. Nunca será
necesario cambiar además la Vista.
Programación orientada a eventos

• Para conseguir la independencia de los componentes, es conveniente definir

la vista como una interfaz que especifique:
• Constantes de eventos.
• Métodos para que el controlador pueda consultar y actualizar la información.
• Métodos para registrar los controladores que estarán a la escucha de eventos.
• En un buen diseño, varias vistas podrían disponer del mismo controlador.
También es posible disponer de varios controladores especializados, cada uno
controlando distintos eventos.
• En ciertas ocasiones, la vista también interactúa con el modelo.

Para nuestro ejemplo (de la figura 2.1) vamos a aplicar MVC considerando el
diagrama siguiente (figura 4.1). La principal diferencia con lo que teníamos
(comparar con figura 3.3) es la independencia que le hemos dado a la componente
vista, no referenciando directamente a la clase concreta VistaSumadorImpl. Para
acceder esta clase se debe realizar a través de la interface Vista.

Figura 4.1
Aplicación del patrón MVC al ejemplo del Sumador de números.

27
Programación orientada a eventos

Se agrega entonces la implementación de la interfaz siguiente:

Recuerda que a la implementación de la interfaz Vista solo debes agregar la palabra

reservada@Override antes de la definición del método que estamos sobre
escribiendo.

5. CASO PROPUESTO

Se propone un caso sencillo donde debe implementar la gestión del saldo de una
cuenta vista con las 3 posibles operaciones:
• void depositar(double): ingresar dinero a la cuenta.
28
• double extraer(double): extraer dinero de la cuenta.
• double consultarSaldo(): consultar el saldo.

Debe modelar la clase cuenta considerando los siguientes datos:

• Titular de la cuenta, donde este titular se caracteriza por su nombre y su edad.
• Saldo en la cuenta del titular.

Reglas de negocio:
• Al instanciar una cuenta esta debe ser abierta con un saldo mínimo de 2 UTM
y el titular debe ser mayor de edad.
• El usuario no puede sacar más dinero de lo que tiene disponible.
• Cada vez que se realiza un giro debe descontar el 1% de lo que tenga en la
cuenta antes de concretar la extracción del dinero.

Se solicita lo siguiente:
• Diseña el caso realizando un diagrama de clases considerando el patrón de
diseño Modelo Vista Controlador (MVC). Súbelo al foro para que tus
compañeros y docente lo discutamos.
• Dibuja la interfaz con la que interactúa el usuario antes de programarla.
Súbela al foro también.
• Programa esta aplicación usando componentes MVC.