New 2 Java: Construir una Aplicación: 3.- Recibir Entradas de Usuario

�Qu� signigfica implements ActionListener?

Cuando escribimos implements ActionListener en nuestra declaraci�n de clase, nos comprometemos a implementar, o proporcionar el c�digo, para cualquier m�todo declarado en el interface ActionListener. En otras palabras, cualquier m�todo declarado en ActionListener tiene que ser definido en nuestra clase, la clase que implementa ActionListener. Todo esto se explica abajo.

�Classes contra Interfaces

Las clases son plantillas de objetos. Definen el tipo de objetos que datos que contendr� y los m�todos para operar con esos datos. Un ejemplar de esa clase es la plantilla rellena con los datos y las llamadas a los m�todos-- el ejemplar es el objeto.

Podemos crear muchos ejemplares de la misma clase, creando mucho objetos de ese tipo. Cada objeto tiene sus propios datos, y algunos objetos comparten datos espec�ficos, dependiendo de si han sido declarados datos static o instance.

No tenemos que escribir una clase desde el principio. Si ya existe una clase que tiene caracter�sticas similares a la que queremos crear, podemos Usar la palabra clave extends para heredar campos y m�todos desde otra clase. Luego a�adimos mas campos y m�todos para crear una clase m�s rica que la clase padre. Pero no tenemos que conformarnos con los campos o m�todos heredados. Podemos sobreescribir m�todos, u ocultar datos de las clase padre para cumplir con nuestras necesidades.

Esto es cierto para clases concretas, pero no para los interfaces.

Los interfaces declaran m�todos, y posiblemente campos est�ticos, pero no definen m�todos. En su lugar, los interfaces s�lo declaran los m�todos sin ninguna instrucci�n dentro de ellos. En otras palabras, los interfaces son como plantillas que siempre ser�n plantillas. No podemos ejemplarizar un interface para crear un objeto. Son como clases sin implementaci�n. �Entonces por qu� existen?

Sirven para un prop�sito: para forzar al desarrollador a proporcionar esos m�todos, con detalles, en la clase que implements el interface. En otras palabras, implementar un interface significa que estamos haciendo la promesa de usar ciertos m�todos, pero nosotros, los desarrolladores, definimos los detalles de esos m�todos.

�Por qu� es esto �til o necesario?

Supongamos que tenemos un equipo de desarrolladores que est�n creando clases para hacer diferentes tipos de objetos animales.Todos esos animales van a tener dos cosas en com�n:

• Usan alguna foma de locomoci�n.
• Comen alguna clase de comida.

La diferencia entre los animales est� en c�mo se mueven y qu� y c�mo comen. En otras palabras, cada uno necesita tener los m�todos locomotion() y eat(), pero cada individuo, cada clase animal, define los detalles de esos m�todos separadametne bas�ndose en las necesidades de las especies de animales.

Dise�amos un interface para asegurarnos de que cada objeto animal hace ciertas cosas, y nuestro equipo desarrolla clases como �sta:

En el interface Animal, los m�todos est�n declarados, pero no definidos. Observa que esos m�todos (en azul) est�n definidos en clases concretas Shark y Dog. En el ejemplo de arriba, cada m�todo imprime una l�nea de texto, indicando lo que come el animal y como se mueve desde un lugar a otro. La �ltima clase es una aplicaci�n que inicializa las dos clases concretas Shark y Dog, y llama a los m�todos de esas clases, usando el operador punto.

Cuando compilamos y ejecutamos AnimalTest, obtenemos el siguiente resultado:

I swim.
I hunt for seals.
I run on four legs.
I eat kibble.

Los juegos son otro ejemplo de c�mo podr�amos implementar interfaces. Por ejemplo, podr�amos dise�ar los siguientes juegos: Water Pistol Wars, Asteroid Archery, Rubberband Rally, y Cannon Craze. Todos implican armas de fuego, pero las armas y lo que disparan son diferentes. Un interface se podr�a asegurar de que todo juego implemente un m�todo fire(), pero es cosa de cada dise�ador del juego la forma de disparar y el tipo de munici�n utilizada.

�Manejo de Eventos B�sico

El API Java tiene muchos interfaces que podemos implementar. Para programaci�n GUI, un interface se asegura de que proporcionamos alguna funcionalidad en un m�todo espec�fico. Para hacer el Dive Log interactivo y hacer algo con el texto introducido en los campos de texto, necesitamos implementar el interface ActionListener y manejar los eventos.

Antes de entrar en detalles sobre el interface ActionListener y alguna de sus subclases, necesitamos entender lo b�sico sobre el manejo de eventos.

Los eventos son objetos que un usuario inicia, como un texto introducido, un bot�n pulsado, o un movimiento del rat�n sobre un componente. El componente listen (escucha) un evento si quiere handle (manejar) el evento con una acci�n, como mostar el texto o escribir en una base de datos. Crear una clase dirigida por eventos tiene tres pasos:

1. Decidir qu� tipo de eventos dispara un componente, e implementar el interface correcto.
2. Registrar el componente como un un oyente para ese tipo de evento.
3. Implementar los m�todos manejadores del interface.

Cuando un usuario dispara un evento a trav�s de un componente GUI, se hace una llamada a un m�todo de cualquier objeto que haya sido registrado con el componente como oyente del tipo de evento que tuvo lugar. Un oyente de eventos es un objeto al que se le notifica cuando ocurre un evento. Diez categor�as de eventos GUI representan una clase diferente.

Para crear la clase Diver, s�lo necesitamos conocer los siguientes oyentes de eventos e interfaces:

Los interfaces listener y las clases event est�n en el paquete java.awt.AWTEvent, por eso debemos importar este paquete para usarlos.

Los eventos generados por botones y campos de texto necesitan que la clase implemente el interface ActionListener, lo que hemos hecho para la clase Diver. Luego, necesitamos registrar los componentes que queremos que escuchen estos eventos con el m�todo addActionListener, que toma un objeto evento como un argumento. Los m�todos de registro se llaman addxxxListener, donde xxx es el tipo de interface implementado. Por ejemplo, para registrar un campo de texto para escuchar eventos, usamos lo siguiente:

JTextfield textfield1 = new JTextfield();
textfield1.addActionListener( this );

La palabra clave this se refiere a esta clase, siendo la clase Diver, la que implements el interface apropiado. Una vez que la clase implementa un ActionListener, y hemos llamado al m�todo addxxxListener sobre el objeto de entrada del que queremos escuchar eventos, podemos definir el m�todo que debemos implementar del interface ActionListener.

Recuerda que como ActionListener es un interface, nos hemos comprometido a implementar sus m�todos. La documentaci�n revela s�lo un m�todo que necesitamos definir:

public void actionPerformed(ActionEvent e)

Este m�todo es invocado cuando ocurre un evento, como una pulsaci�n de rat�n o de la tecla return. Definimos lo que queremos que suceda dentro de este m�todo, si se muestra el texto, se escriben ficheros, o alguna otra acci�n.

La imagen de arriba muestra el proceso de manejo de eventos para un campo de texto.

Luego, escribimos el m�todo que construye el panel emerg. Construirmos este m�todo buildEmergencyPanel como lo hemos hecho con los otros dos:

El m�todo buildTrainingPanel que necesitamos construir luego usa check boxes en lugar de campos de texto. Cada check box se contruye con texto, por eso necesitamos crear etiquetas.

La distribuci�n de este panel hace uso de una simple parrilla que consta de 1 columna y 6 filas. Este ejemplo tambi�n suministra una separaci�n de 10 y 20 respectivamente.

El manejo de eventos de los Check box requiere que implementemos el interface ItemListener. Por eso para reistar los check boxes como fuentes de eventos, a�adimos un oyente llamando la m�todo addItemListener.

En lugar de usar la palabra clave this como par�metro en el m�todo addItemListener para decirle que busque en esta clase las instrucciones para ver c�mo manejar estos eventos, le decimos que busque en la referencia de variable handler.

Recuerda a�adir este trozo de c�digo en la parte superior de la clase Diver:

// Class to handle functionality of check boxes  
ItemListener handler = new CheckBoxHandler();

Cuando crees otra clase que maneje la funcionalidad de los objetos, nombra la clase como par�metro en el m�todo addItemListener. Aprenderemos m�s sobre las clases internas m�s adelante.

Para registrar un oyente con el objeto ow, escribimos lo siguiente:

ow.addItemListener(handler);

Cuando especificamos que la instrucci�n est� en esta(this) clase, o proporcionmos el nombre de una clase, revelamos donde est� localizado el m�todo prometido. Recuerda, para la funcionalidad del manejo de eventos, implementamos ciertos interfaces. Haciendo esto, nos comprometemos a proporcionar la implementaci�n, o los detalles, de los m�todos declarados en ese interface. Las instrucciones est�n especificamente encerradas en esos m�todos que prometimos proporcionar.

La clase Diver implementa el interface ActionListener. Por lo tanto, la clase this debe implementar el m�todo actionPerformed(ActionEvent e). Cuando ocurre un evento, se llama autom�ticamente a actionPerformed porque registramos el objeto llamando a addTypeListener.

La clase Diver no implementa el interface ItemListener. En su lugar, la clase interna implementa el interface ItemListener y su implementaci�n de m�todo requerida.

Hasta ahora hemos hecho esto en la clase Diver:

• Implementado el interface ActionListener.
• Declarado variables para objetos.
• Ejemplarizado esos objetos en el constructor de la clase.
• Escrito m�todos para crear panales que contienen los objetos GUI.
• Registrado algunos de esos objetos como fuentes de eventos.

Ahora, necesitamos proporcionar la instrucci�n para que suceda algo cuando un usuario pulsa Return o pulsa el bot�n Enter dentro del m�todo que prometimos implementar.