Interfaces Listener - II

2. Una vez registrado el objeto que gestionará el evento, perteneciente a una clase que implemento la correspondiente interface Listener. se deben definir los métodos de dicha interface. Siempre hay que definir todos los métodos de la interface. aunque algunos de dichos métodos puedan estar "vacíos". Un ejemplo es la implementación de la interface Win don-Listen er vista en el Apartado 1.3.9 (en la página 18). en el que todos los métodos estaban vacíos excepto windowClosingf).

Interfaces Listener - I

Una vez vistos los distintos eventos que se pueden producir, conviene ver cómo se deben gestionar estos eventos. A continuación se detalla cómo se gestionan los eventos según el modelo de Java: 

1. Cada objeto que puede recibir un evento (event so urce), "registra" uno o más objetos para que los gestionen (event listener). Esto se hace con un método que tiene la forma. eventSourceObj ect.addEventListener(eventListenerObject); donde eventSourceObject es el objeto en el que se produce el evento, y eventListenerObject es el objeto que deberá gestionar los eventos. La relación entre ambos se establece a través de una interface Listener que la clase del eventListenerObject debe implementar. Esta interface proporciona la declaración de los métodos que serán llamados cuando se produzca el evento. La interface a implementar depende del tipo de evento. La Tabla 5.3 relaciona los distintos tipos de eventos, con la interface que se debe implementar para gestionarlos. Se indican también los métodos declarados en cada interface. Es importante observar la correspondencia entre eventos e interfaces Listener. Cada evento tiene su interface. excepto el ratón que tiene dos interfaces MouseListener y MouseMotionListener. La razón de esta duplicidad de interfaces se encuentra en la peculiaridad de los eventos que se producen cuando el ratón se mueve. Estos eventos, que se producen con muchísima más frecuencia que los simples clicks. por razones de eficiencia son gestionados por una interface especial: MouseMotionListener. Obsérvese que el nombre de la interface coincide con el nombre del evento, sustituyendo la palabra Event por Listener.

Relación entre Componentes y Eventos - II

La relación entre componentes y eventos indicada en la Tabla 5.1 pueden inducir a engaño si no se tiene en cuenta que los eventos propios de una super-clase de componentes pueden afectar también a los componentes de sus sub-clases. Por ejemplo, la clase TextArea no tiene ningún evento específico o propio, pero puede recibir los de su superlase TextComponent. 

La Tabla 5.2 muestra los componentes del AWT y todos los tipos de eventos que se pueden producir sobre cada uno de ellos, teniendo en cuenta también los que son específicos de sus superclases. Entre ambas tablas se puede sacar una idea bastante precisa de qué tipos de eventos están soportados en Java y qué eventos concretos puede recibir cada componente del AWT. En la práctica, no todos los tipos de evento tienen el mismo interés.

Relación entre Componentes y Eventos - I

La Tabla 5.1 muestra los componentes del AWT y los eventos específicos de cada uno de ellos, así como una breve explicación de en qué consiste cada tipo de evento.

Jerarquía de eventos

deriva la clase A WTEvent. de la que dependen todos los eventos de AWT. La Figura 5.2 muestra la jerarquía de clases para los eventos de Java. Por conveniencia, estas clases están agrupadas en el package java.awt.event. Los eventos de Java pueden ser de alto y bajo nivel. 

Los eventos de alto nivel se llaman también eventos semánticos, porque la acción de la que derivan tiene un significado en sí misma, en el contexto de las interfaces gráficas de usuario. Los eventos de bajo nivel son las acciones elementales que hacen posible los eventos de alto nivel. Son eventos de alto nivel los siguientes eventos: los cuatro que tienen que ver con clicar sobre botones o elegir comandos en nienús (ActionEvent). cambiar valores en barras de desplazamiento (AdjustmentEvent). elegir valores (ItemEvents) y cambiar el texto (TextEvent). En la Figura 5.2 los eventos de alto nivel aparecen con fondo gris. Los eventos de bajo nivel son los que se producen con las operaciones elementales con el ratón, teclado, containers y windows. Las seis clases de eventtos de bajo nivel son los eventos relacionados con componentes (CotnponentEvent). con los containers (ContainerEvent). con pulsar teclas (KeyEvent). con mover, arrastrar, pulsar y soltar con el ratón (MouseEvent). con obtener o perder el focus (.FocusEvent) y con las operaciones con ventanas (WindouEvent). 

El modelo de eventos se complica cuando se quiere connstruir un tipo de componente propio, no estándar del AWT. En este caso hay que interceptar los eventos de bajo nivel de Java y adecuarlos al problema que se trata de resolver. Este es un tema que no se va a tratar en este manual.

Componentes y eventos soportados por el AWT de Java

Jerarquía de Componentes Como todas las clases de Jara, los componentes utilizados en el AWT pertenecen a una determinada jerarquía de clases, que es muy importante conocer. Esta jerarquía de clases se muestra en la Figura 5.1. Todos los componentes descienden de la clase Componente de la que pueden ya heredar algunos métodos interesantes. Elpackage al que pertenecen estas clases se llama java.awt.

A continuación se resumen algunas características importantes de los componentes mostrados en la Figura Todos los Componente (excepto Window y los que derivan de ella) deben ser añadidos a un Container. También un Container puede ser añadido a otro Container. 

2. Para añadir un Component a un Container se utiliza el método add() de la clase Container: containerName.add(componentName); 

3. Los Containers de máximo nivel son las Windows (Frames y Dialogs). Los Panels y ScrollPanes deben estar siempre dentro de otro Container. 

4. Un Component sólo puede estar en un Container. Si está en un Container y se añade a otro, deja de estar en el primero. 

5. La clase Component tiene una serie de funcionalidades básicas comunes (variables y métodos) que son heredadas por todas sus sub-clases.

Proceso a seguir para crear una aplicación interactiva (orientada a eventos)

Para avanzar un paso más. se resumen a continuación los pasos que se pueden seguir para construir una aplicación orientada a eventos sencilla, con interface gráfica de usuario: 

1. Determinar los componentes que van a constituir la interface de usuario (botones, cajas de texto, menús. etc.). 

2. Crear una clase para la aplicación que contenga la función main(). 

3. Crear una clase Ventana. sub-clase de Frame. que responda al evento WindowClosingQ. 

4. La función main() deberá crear un objeto de la clase Ventana (en el que se van a introducir las componentes seleccionadas) y mostrarla por pantalla con el tamaño y posición adecuados. 

5. Añadir al objeto Ventana todos los componentes y menús que deba contener. Se puede hacer en el constructor de la ventana o en el propio método main(). 

6. Definir los objetos Listener (objetos que se ocuparán de responder a los eventos, cuyas clases implementan las distintas interfaces Listener) para cada uno de los eventos que deban estar soportados. En aplicaciones pequeñas, el propio objeto Ventana se puede ocupar de responder a los eventos de sus componentes. En programas más glandes se puede crear uno o más objetos de clases especiales para ocuparse de los eventos. 

7. Finalmente, se deben implementar los métodos de las interfaces Listener que se vayan a hacer cargo de la gestión de los eventos.

Objetos "event source" y objetos "event listener"

El modelo de eventos de Java está basado en que los objetos sobre los que se producen los eventos (event sources) "registran" los objetos que habrán de gestionarlos (event listeners). para lo cual los event listeners habrán de disponer de los métodos adecuados. Estos métodos se llamarán automáticamente cuando se produzca el evento. 

La forma de garantizar que los event listeners disponen de los métodos apropiados para gestionar los eventos es obligarles a implementar una determinada interface Listener. Las interfaces Listener se corresponden con los tipos de eventos que se pueden producir. 

En los apartados siguientes se verán con más detalle los componentes que pueden recibir eventos. los distintos tipos de eventos y los métodos de las interfaces Listener que hay que definir para gestionarlos. En este punto es muy importante ser capaz de buscar la información correspondiente en la documentación de Java. Las capacidades gráficas del AWT resultan pobres y complicadas en comparación con lo que se puede conseguir con Visual Basic, pero tienen la ventaja de poder ser ejecutadas casi en cualquier ordenador y con cualquier sistema operativo.

Creación de una Interface Gráfica de Usuario

Para construir una interface gráfica de usuario hace falta: 

1. Un *•contenedor,, o container, que es la ventana o paite de la ventana donde se situarán los componentes (botones, barras de desplazamiento, etc.) y donde se realizarán los dibujos. Se correspondería con un formulario o una picture box de Visual Basic. 

2. Los componentes: menús. botones de comando, barras de desplazamiento, cajas y áreas de texto, botones de opción y selección, etc. Se corresponderían con los controles de Visual Basic. 

3. El modelo de eventos. El usuario controla la aplicación actuando sobre los componentes, de ordinario con el ratón o con el teclado. Cada vez que el usuario realiza una determinada acción, se produce el evento correspondiente, que el sistema operativo transmite al AWT. El AWT crea un objeto de una determinada clase de evento, derivada de AWTEvent. Este evento es transmitido a un determinado método para que lo gestione. En Visual Basic el entorno de desarrollo crea automáticamente el procedimiento que va a gestionar el evento (uniendo el nombre del control con el tipo del evento mediante el carácter _) y el usuario no tiene más que introducir el código. En Java esto es un poco más complicado: el componente u objeto que recibe el evento debe ''registrar*' o indicar previamente qué objeto se va a hacer cargo de gestionar ese evento. 

En los siguientes apartados se verán con un cierto detalle estos tres aspectos del AWT. Hay que considerar que el AWT es una parte muy extensa y complicada de Java, sobre la que existen libros con muchos cientos de páginas.

EL AWT (ABSTRACT WINDOWS TOOLKIT)

QUÉ ES EL AWT

 El AWT (Abstract Windows Toolkit) es la paite de Java que se ocupa de construir interfaces gráficas de usuario. Aunque el AWT ha estado presente en Java desde la versión 1.0. la versión 1.1 representó un cambio notable, sobre todo en lo que respecta al modelo de eventos. La versión 1.2 ha incorporado un modelo distinto de componentes llamado Swing, que también está disponible en la versión 1.1 como package adicional. En este Capítulo se seguirá el AWT de Java 1.1. también soportado por la versión 1.2.

Clases TimeZone y SimpleTimeZone

La clase TimeZone es también una clase abstract que sirve para definir la zona horaria. Los métodos de esta clase son capaces de tener en cuenta el cambio de la hora en verano para alionar energía. La clase SimpleTimeZone deriva de TimeZone y es la que conviene utilizar. El valor por defecto de la zona horaria es el definido en el ordenador en que se ejecuta el programa. Los objetos de esta clase pueden ser utilizados con los constructores y algunos métodos de la clase Calendar para establecer la zona horaria.

Clases DateFormat y SimpleDateFormat

DateFormat es una clase abstract que pertenece al package jara.text y no al package jara.útil, como las vistas anteriormente. La razón es para facilitar todo lo referente a la intemacionalización. que es un aspecto muy importante en relación con la conversión, que permite dar formato a fechas y horas de acuerdo con distintos criterios locales. Esta clase dispone de métodos static para convertir Strings representando fechas y horas en objetos de la clase Date, y viceversa. La clase SimpleDateFormat es la única clase derivada de DateFormat. Es la clase que conviene utilizar. Esta clase se utiliza de la siguiente forma: se le pasa al constructor un String definiendo el formato que se desea utilizar. 

Por ejemplo:

import java.útil.*;
import j ava.text.*;

class SimpleDateForm {

public static void main(String arg[]) throws ParseException {

SimpleDateFormat sdfl = new SimpleDateFormat("dd-MM-yyyy hh:zran:ss");

SimpleDateFormat sdf2 = new SimpleDateFormat("dd-MM-yy");

Date d = sdf1.parse("12-04-1563 11:23:45");

String s = sdf2.format(d);

System.out.println(s);

}

}

La documentación de la clase SimpleDateFormat proporciona abundante información al respecto, incluyendo algunos ejemplos.

Clases Calendar y GregoriauCaleudar

La clase Calendar es una clase abstract que dispone de métodos para convertir objetos de la clase Date en enteros que representan fechas y horas concretas. La clase GregoriauCaleudar es la única clase que deriva de Calendar y es la que se utilizará de ordinario. Java tiene una forma un poco particular para representar las fechas y horas: 

1. Las horas se representan por enteros de 0 a 23 (la hora o va de las 00:00:00 hasta la 1:00:00). y los minutos y segundos por enteros entre 0 y 59. 

2. Los días del mes se representan por enteros entre 1 y 31 (lógico). 

3. Los meses del año se representan mediante enteros de 0 a 11 (no tan lógico). 

4. Los años se representan mediante enteros de cuatro dígitos. Si se representan con dos dígitos, se resta 1900. Por ejemplo, con dos dígitos el año 2000 es para Java el año 00.

La clase Calendar tiene una serie de variables miembro y constantes (variables final) que pueden resultar muy útiles: 

• La variable int AM_PM puede tomar dos valores: las constantes enteras AM y PM. 

• La variable int DAYOFWEEK puede tomar los valores int SUNDAY. MONDAY. TUESDAY. WEDNESDAY, THURSDAY. FRIDAY y SATURDAY. 

• La variable int MONTH puede tomar los valores int JANUARY. FEBRUARY. MARCH, APRIL, MAY. JUNE. JULY, AUGUST, SEPTEMBER. OCTOBER. NOYEMBER. DECEMBER. Para hacer los programas más legibles es preferible utilizar estas constantes simbólicas que los correspondientes números del 0 al 11. 

• La variable miembro HOUR se utiliza en los métodos get() y set() para indicar la hora de la mañana o de la tarde (en relojes de 12 horas, de 0 a 11). La variable HOUR OF DAY sirve para indicar la hora del día en relojes de 24 horas (de 0 a 23). 

• Las variables DAY OF WEEK. DAY_OF_WEEK_IN_MONTH. DAY OF MONTH (o bien DATE). DAY OF YEAR, WEEK_OF_MONTH, WEEK OF YEAR tienen un significado evidente. 

• Las variables ERA. YEAR. MONTH. HOUR. MINUTE. SECOND. MILLISECOND tienen también un significado evidente.

Clase Date

La clase Date representa un instante de tiempo dado con precisión de milisegundos. La información sobre fecha y hora se almacena en un entero long de 64 bits que contiene los milisegundos transcurridos desde las 00:00:00 del 1 de enero de 1970 GMT (Greemvich mean time). Ya se verá que otras clases permiten a partir de un objeto Date obtener información del año. mes. día. horas, minutos y segundos. A continuación se muestran los métodos de la clase Date, habiéndose eliminado los métodos declarados obsoletos (deprecated) en el JDK 1.2:

Compiled from Date.java

public class java.útil.Date extends java.lang.Object implements

java.io.Serializable, java.lang.Cloneable, java.lang.Comparable {
public java.útil.Date();
public java.útil.Date(long);
public boolean after(java.útil.Date);
public boolean before(java.útil.Date);
public java.lang.Object clone();
public int compareTo(java.lang.Object);
public int compareTo(java.útil.Date);
public boolean equals(java.lang.Object);
public long getTimeO;
public int hashCodeO;
public void setTime(long);
public java.lang.String toStringO;

}

El constructor por defecto Date() crea un objeto a partir de la fecha y hora acmal del ordenador. El segundo constructor crea el objeto a partir de los milisegundos transcurridos desde el 01/01/1970. 00:00:00 GMT. Los métodos after <) y beforeQ permiten saber si la fecha indicada como argumento implícito (this) es posterior o anterior a la pasada como argumento. Los métodos getTime() y setTiine() permiten obtener o establecer los milisegundos transcurridos desde el 01/01/1970. 00:00:00 GMT para un determinado objeto Date. Otros métodos son consecuencia de las interfaces implementadas por la clase Date. 

Los objetos de esta clase no se utilizan mucho directamente, sino que se utilizan en combinación con las clases que se vana ver a continuación.

OTRAS CLASES DEL PACKAGE JAVA.UTIL

El package jara.útil tiene otras clases interesantes para aplicaciones de distinto tipo, entre ellas algunas destinadas a considerar todo lo relacionado con fechas y horas. A continuación se consideran algunas de dichas clases.

Maps y SortedMaps - Part 3

La clase HashMap implementa la interface Map y está basada en una hash table. mientras que TreeMap implementa SortedMap y está basada en un árbol binario. 4.5.4.8 Algoritmos y otras características especiales: Clases Collections y Arrays La clase Collections (no confundir con la interface Collection. en singular) es una clase que define un buen número de métodos static con diversas finalidades. No se detallan o enumeran aquí porque exceden del espacio disponible. Los más interesantes son los siguientes: 

• Métodos que definen algoritmos:

Ordenación mediante el método mergesort

public static void sort(java.útil.List);

public static void sort(java.útil.List, java.útil.Comparator);

Eliminación del orden de modo aleatorio

public static void shuffie(java.útil.List);

public static void shuffie(java.útil.List, java.útil.Random);
Inversión del orden establecido

public static void reverse(java.útil.List);
Búsqueda en una lista

public static int binarySearch(java.útil.List, java.lang.Object);
public static int binarySearch(java.útil.List, java.lang.Object,

java.útil.Comparator) ;

Copiar una lista o reemplazar todos los elementos con el elemento especificado

public static void copy(java.útil.List, java.útil.List);
public static void fill(java.útil.List, java.lang.Object);
Cálculo de máximos y mínimos

public static java.lang.Object max(java.útil.Collection);

public static java.lang.Object max(java.útil.Collection, java.útil.Comparator);
public static java.lang.Object min(java.útil.Collection);

public static java.lang.Object min(java.útil.Collection, java.útil.Comparator);

Maps y SortedMaps - Part 2

Muchos de estos métodos tienen un significado evidente, pero otros no tanto. El método entrySetf) devuelve una "vista" del Map como Ser. Los elementos de este Ser son referencias de la interface Map.Entry. que es una interface interna de Map. Esta "vista" del Map como Ser permite modificar y eliminar elementos del Map. pero no añadir nuevos elementos. 

l método get(key) permite obtener el valor a partir de la clave. El método keySetQ devuelve una '•vista" de las claves como Ser. El método values() devuelve una 'vista'' de los valores del Map como Collection (porque puede haber elementos repetidos). El método put() permite añadir una pareja clave/valor, mientras que putAll() vuelca todos los elementos de un Map en otro Map (los pares con clave nueva se añaden: en los pares con clave ya existente los valores nuevos sustituyen a los antiguos). El método remove() elimina una pareja clave/valor a partir de la clave. La interface SortedMap añade los siguientes métodos, similares a los de SortedSet:

Compiled from SortedMap.java

public interface java.útil.SortedMap extends java.útil.Map

{

public abstract java.útil.Comparator comparator();
public abstract java. lang.Object firstKeyO;

public abstract java.útil.SortedMap headMap(java.lang.Object);
public abstract java. lang.Object lastKeyO;

public abstract java.útil.SortedMap subMap(java.lang.Object, java.lang.Object);
public abstract java.útil.SortedMap taiiMap(java.lang.Object);

}

Maps y SortedMaps - Part 1

Un Map es una estructura de datos agrupados en parejas clave/valor. Pueden ser considerados como una tabla de dos columnas. La clave debe ser única y se utiliza para acceder al valor. Aunque la interface Map no deriva de Collection. es posible ver los Maps como colecciones de claves. de valores o de parejas clave/valor. A continuación se muestran los métodos de la interface Map (comando > javap java.utilMap):

Listas

La interface List define métodos para operar con colecciones ordenadas y que pueden tener elementos repetidos. Por ello, dicha interface declara métodos adicionales que tienen que ver con el orden y con el acceso a elementos o rangos de elementos. Además de los métodos de Collection. la interface List declara los métodos siguientes:

Compiled from List.java

public interface java.útil.List extends java.útil.Collection

{

public abstract void add(int, java.lang.Object);

public abstract boolean addAll(int_f java.útil.Collection);

public abstract java.lang.Object get(int);

public abstract int indexOf(java.lang.Object);

public abstract int lastlndexOf(java.lang.Object);

public abstract java.útil.Listlterator listlterator();

public abstract java.útil.Listlterator listlterator(int);

public abstract java.lang.Object remove(int);

public abstract java.lang.Object set(int, java.lang.Object);

public abstract java.útil.List subList(int, int);

}

Los nuevos métodos add() y addAHQ tienen un argumento adicional para insertar elementos en una posición determinada, desplazando el elemento que estaba en esa posición y los siguientes. Los métodos get() y set() penniten obtener y cambiar el elemento en una posición dada. Los métodos indexOfO y lastlndexOfO penniten saber la posición de la primera o la última vez que un elemento aparece en la lista; si el elemento no se encuentra se devuelve -1. 

El método subList(int fromlndex, tolndex) devuelve una "vista" de la lista, desde el elemento fromlndex inclusive hasta el tolndex exclusive. Un cambio en esta "vista"' se refleja en la lista original, aunque no conviene hacer cambios simultáneamente en ambas. Lo mejor es eliminar la "vista" cuando ya no se necesita. 

Existen dos implementaciones de la interface List, que son las clases ArrayList y LinkedList. La diferencia está en que la primera almacena los elementos de la colección en un array de Objects. mientras que la segunda los almacena en una lista vinculada. 

Los arrays proporcionan una fonna de acceder a los elementos mucho más eficiente que las listas vinculadas. Sin embargo tienen dificultades para crecer (hay que reservar memoria nueva, copiar los elementos del array antiguo y liberar la memoria) y para insertar y/o bonar elementos (hay que desplazar en un sentido u en otro los elementos que están detrás del elemento borrado o insertado). Las listas vinculadas sólo penniten acceso secuencial. pero tienen una gran flexibilidad para crecer, para bonar y para insertar elementos. El optar por una implementación u otra depende del caso concreto de que se trate.

Sets y SortedSets

La interface Set sirve para acceder a una colección sin elementos repetidos. La colección puede estar o no ordenada (con un orden natural o definido por el usuario, se entiende). La interface Set no declara ningún método adicional a los de Collection. Como un Set no admite elementos repetidos es importante saber cuándo dos objetos son considerados iguales (por ejemplo, el usuario puede o no desear que las palabras Mesa y mesa sean consideradas iguales). Para ello se dispone de los métodos equalsf) y hashcode(). que el usuario puede redefinir si lo desea. Utilizando los métodos de Collection. los Sets permiten realizar operaciones algebraicas de unión, intersección y diferencia. 

Por ejemplo. sl.containsAU(s2) permite saber si s2 está contenido en si: sl.addAll(s2) permite convertir si en la unión de los dos conjuntos: sl.retainAll(s2) permite convertir si en la intersección de si y s2: finalmente. sl.retnoveAll(s2) convierte si en la diferencia entre si y s2. La interface SortedSet extiende la interface Set y añade los siguientes métodos:

Compiled from SortedSet.java

public interface java.útil.SortedSet extends java.útil.Set

{

public abstract java.útil.Comparator comparator();
public abstract java.lang.Object first();

public abstract java.útil.SortedSet headSet(java.lang.Object);
public abstract java.lang.Object last();

public abstract java.útil.SortedSet subSet(java.lang.Object, java.lang.Object);
public abstract java.útil.SortedSet tailSet(java.lang.Object);

}

que están orientados a trabajar con el "orden". El método comparatorf) permite obtener el objeto pasado al constructor para establecer el orden. Si se ha utilizado el orden natural definido por la interface Comparable. este método devuelve nuil. Los métodos first() y lastf) devuelven el primer y último elemento del conjunto. Los métodos headSetQ. subSetQ y tailSetf) sirven para obtener sub- conjuntos al principio, en medio y al final del conjunto original (los dos primeros no incluyen el límite superior especificado).

Existes dos implementociones de conjuntos: la clase HashSet implemento la interface Set, mientras que la clase TreeSet implemento SortedSet. La primera está basada en una hash table y la segunda en un TreeMap. Los elementos de un HashSet no mantienen el orden natural, ni el orden de introducción. Los elementos de un TreeSet mantienen el orden natural o el especificado por la interface Comparator. Ambas clases definen constructores que admiten como argumento un objeto Collection. lo cual permite convertir un HashSet en un TreeSet y viceversa.

Interfaces Comparable y Comparator

Estas interfaces están orientadas a mantener ordenadas las listas, y también los sets y maps que deben mantener un orden. Para ello se dispone de las interfaces java.lang. Comparable y java.útil. Comparator (obsérvese que pertenecen a packages diferentes). La interface Comparable declara el método compareTof) de la siguiente forma:

public int compareTo(Object obj)

que compara su argumento implícito con el que se le pasa por ventana. Este método devuelve mi entero negativo, cero o positivo según el argumento implícito (this) sea anterior, igual o posterior al objeto obj. Las listas de objetos de clases que implementan esta interface tienen un orden natural. En Java 1.2 esta interface está implementada -entre otras- por las clases String. Character. Date. File. BigDecimal. Biglnteger. Byte. Short. Integer. Long. Float y Double. 

Téngase en cuenta que la implementación estándar de estas clases no asegura un orden alfabético correcto con mayúsculas y minúsculas, y tampoco en idiomas distintos del inglés. Si se redefine. el método compareTo() debe ser programado con cuidado: es muy conveniente que sea coherente con el método equalsf) y que cumpla la propiedad transitiva. Para más información, consultar la documentación del JDK 1.2. 

Las listas y los arrays cuyos elementos implementan Comparable pueden ser ordenadas con los métodos static Collections.sortf) y Arrays.sort(). La interface Comparator permite ordenar listas y colecciones cuyos objetos pertenecen a clases de tipo cualquiera. Esta interface permitiría por ejemplo ordenar figuras geométricas planas por el área o el perímetro. Su papel es similar al de la interface Comparable, pero el usuario debe siempre proporcionar una implementación de esta clase. Sus dos métodos se declaran en la forma:

public int compare(Object ol, Object o2)

public boolean equals(Object obj)

El objetivo del método equalsQ es comparar Comparators. El método compare() devuelve un entero negativo, cero o positivo según su primer argumento sea anterior, igual o posterior al segundo. Los objetos que implementan Comparator pueden pasarse como argumentos al método Collections.sort() o a algunos constructores de las clases TreeSet y TreeMap. con la idea de que las mantengan ordenadas de acuerdo con dicho Comparator. Es muy importante que comparef) sea compatible con el método equalsf) de los objetos que hay que mantener ordenados. Su implementación debe cumplir unas condiciones similares a las de compareTo(). 

Java 1.2 dispone de clases capaces de ordenar cadenas de texto en diferentes lenguajes. Para ello se puede consultar la documentación sobre las clases CollationKey. Collator y sus clases derivadas, en el package ja va. text.

Interfaces Iterator y Listlterator

La interface Iterator sustituye a Enumeration. utilizada en versiones anteriores del JDK. Dispone de los métodos siguientes:

Compiled from Iterator.java

public interface java.útil.Iterator
{

public abstract boolean hasNext();
public abstract java.lang.Object next();
public abstract void remove();

}

El método remove() permite borrar el último elemento accedido con nextQ. Es la única forma segura de eliminar un elemento mientras se está recorriendo una colección. Los métodos de la interface Listlterator son los siguientes:

Compiled from Listlterator.java

public interface java.útil.Listlterator extends java.útil.Iterator

{

public abstract void add(java.lang.Object);
public abstract boolean hasNext();
public abstract boolean hasPrevious();
public abstract java.lang.Object next();
public abstract int nextlndex();
public abstract java.lang.Object previous();
public abstract int previousIndex();
public abstract void remove();
public abstract void set(java.lang.Object);

> 

La interface Listlterator permite recorrer una lista en ambas dilecciones, y hacer algunas modificaciones mientras se recorre. Los elementos se numeran desde 0 a n-L pero los valores válidos para el índice son de 0 a n. Puede suponerse que el índice i está en la frontera entre los elementos i-1 e i: en ese caso previouslndex0 devolvería i-i y nextlndexQ devolvería i. Si el índice es 0. previousIndexQ devuelve -1 y si el índice es n nextlndexQ devuelve el resultado de size().

Interface Collection

La interface Collection es implementada por los conjuntos (sets) y las listas (lists). Esta interface declara una serie de métodos generales utilizables con Sets y Lists. La declaración o header de dichos métodos se puede ver ejecutando el comando > javap jara.útil. Collection en una ventana de MS-DOS. El resultado se muestra a continuación:

public interface java.útil.Collection
{

public      abstract                                boolean add(java.lang.Object);                              // opcional

public      abstract                                boolean addAll(java.útil.Collection);                       // opcional

public      abstract                                void clear(); // opcional

public      abstract   boolean contains(java.lang.Object);

public      abstract   boolean containsAll(java.útil.Collection);

public      abstract   boolean equals(java.lang.Object);

public      abstract   int hashCode();

public      abstract   boolean isEmptyO;

public      abstract   java.útil.Iterator iterator();

public      abstract                                boolean remove(java.lang.Object);                           // opcional

public      abstract   boolean removeAll(java.útil.Collection); // opcional

public      abstract   boolean retainAll(java.útil.Collection); // opcional

public      abstract   int size();

public      abstract   java.lang.Object toArray()[];

public      abstract   java.lang.Object toArray(java.lang.Object[])[];

}

A partir del nombre, de los argumentos y del valor de retomo, la mayor paite de estos métodos resultan autoexplicativos. A continuación se introducen algunos coméntanos sobre los aspectos que pueden resultar más novedosos de estos métodos. 

Los detalles se pueden consultar en la documentación de Java. Los métodos indicados como "// opcional" (estos caracteres han sido introducidos por los autores de este manual) no están disponibles en algunas implementaciones. como por ejemplo en las clases que no permiten modificar sus objetos. Por supuesto, dichos métodos deben ser definidos, pero lo que hacen al ser llamados es lanzar una UusupportedOperatiouException. El método add() trata de añadir un objeto a una colección, pero puede que no lo consiga si la colección es un set que ya tiene ese elemento. Devuelve true si el método ha llegado a modificar la colección. 

Lo mismo sucede con addAllf). El método removef) elimina un único elemento (si lo encuentra); devuelve true si la colección ha sido modificada. El método iteratorQ devuelve una referencia Iterator que permite recorrer una colección con los métodos uext() y hasNext(). Permite también borrar el elemento actual con retnove(). Los dos métodos toArray() permiten convertir una colección en un array.