SCJP 5 - Genericos

Estudiando para dar mi examen de SCJP 5 encontré algo que llaman "genéricos". Recordarás que ahora las colecciones ahora pueden ser con tipo:

ArrayList perros=new ArrayList();
perros.add(new Perro("Fido"));


se ve bonito, y luego bueno de esto es que el
compilador no permitirá algo como esto:

perros.add(new Integer(1));


Así, también se cumple la herencia:

List
perros=new ArrayList ();

Pero esto no se puede hacer:

import java.util.*;


class Animal{}
class Perro extends Animal{}


public class Test {
public static void main(String[] args){
List<
Animal > animales=new ArrayList< Perro >();
}

}



¿Por qué? ¡si Perro ES-UN animal! Pues bien, esto corrige un problema que tienen los arreglos comunes:



import java.util.*;
class Animal{}
class Perro extends Animal{}
class Gato extends Animal{}
public class Test {
public static void main(String[] args){

Perro[] perros=new Perro[]{new Perro()}; //arreglo de perros

agregar(perros);
}

private static void agregar(Animal[] animales) { //es permisible xq Perro ES-UN Animal

animales[0]=new Gato(); //OUCH!! esto no debería ser

}

}



Compila, y cuando se ejecuta manda una excepción (ArrayStoreException). La cuestión es que las colecciones con tipo asegura que los valores que se les pasa no tengan errores de este tipo al momento de la compilación. Por ello, debe asegurar que sean del mismo tipo-de-la-colección. Entonces, esto no compilaría, porque las colecciones se aseguran que tengan el mismo tipo.

//...
public static void main(String[] args){
List perros=new ArrayList();
perros.add(new Perro());

agregar(perros); //no se puede aplicar tipos de colecciones diferentes.

}

private static void agregar(List animales) {
animales.add(new Gato());
}
//...


Pero, claro está,
no vamos a crear tantos métodos cómo subclases tengamos . Aquí entran los "genéricos". Se puede declarar parámetros de métodos que sean de tipo (subtipos o supertipos) de una clase en especial. Entonces, para que nuestro método compile aceptando cualquier colección, debería ser así:

//..
public static void main(String[] args){
List perros=new ArrayList();
perros.add(new Perro());
agregar(perros);

List gatos=new ArrayList();
agregar(gatos); //tambien puedo llamar al mismo método


}

private static void agregar(List animales) { //usando genéricos

//animales.add(new Gato()); //pero esta línea no va a compilar
for(Animal animal:animales) {
//pero puedo manejar cada elemento por igual
}
}
//..


Ajá, con esto aseguro que solo se permitan manejar todos por igual. Pero, si deseo agregar elementos a la colección? Java no va a permitir cualquier cosa que se agregue. Para ello se puede utilizar la palabra clave
super en lugar de extends . Aquí un código más completo para entender cómo funciona:

import java.util.*;
abstract class Animal{ //la clase Animal, tambien puede ser interface
public abstract void dejarseRevisar();
}
class Perro extends Animal{ //La implementacion en Perro
public void dejarseRevisar() {
System.out.println("El Perro se deja revisar");
}}
class Gato extends Animal{ //La implementacion en Gato
public void dejarseRevisar() {
System.out.println("El Gato se deja revisar");
}}
class Poodle extends Perro{ //La implementacion en Poodle que ES-UN Perro
public void dejarseRevisar() {
System.out.println("El Poodle se deja revisar");
}}
public class Test {
public static void main(String[] args){

Veterinario veterinario=new Veterinario(); //tenemos un Veterninario


List perros=new ArrayList(); //creamos nuestra lista de perros
perros.add(new Perro()); //agregamos uno

veterinario.revisar(perros); //lo mandamos a revisar, es tratado como Animal


List gatos=new ArrayList(); //creamos nuestra lista de gatos
gatos.add(new Gato());

veterinario.revisar(gatos); //lo mandamos a revisar, es tratado como un Animal


List poodles=new ArrayList(); //creamos nuestra lista de poodles
poodles.add(new Poodle());

veterinario.revisar(poodles); //.... idem...


List animales=new ArrayList(); //creamos una lista de animales

veterinario.agregarPerros(animales); //y lo manejamos solo para perros a pesar que es una coleccion de animales

}

}
class Veterinario{

void revisar(List animales){ //todos son tratados como animales

for(Animal animal:animales)
animal.dejarseRevisar();
}

void agregarPerros(List perros){

perros.add(new Perro());
perros.add(new Poodle());

//perros.add(new Gato()); //no lo permite, porque lo vamos a manejar como colección de Perros


}
}


Bacán, no? (je). además, esto fue un ejemplo para los argumentos, pero también funciona en variables (con ejemplos de los que no pueden ser compilablres):

List list = new ArrayList(); //compila
List aList = new ArrayList(); //compila

List foo = new ArrayList(); //no compila
List cList = new ArrayList(); //no compila porque Integer no ES-UN Perro

List bList = new ArrayList(); //compila

List dList = new ArrayList(); //no compila porque Perro no es una super-clase de Animal


Ahora, dirás "yo también quiero tener mi clase que permita genéricos". Pues es sencillo. Pongamos el escenario: imaginemos que tengamos una lógica para manejar los alquileres de lo que fuere:

import java.util.*;
class Alquilar{
private List listaAlquiler;
private int maxAlquiler;
public Alquilar(int max, List lista){
maxAlquiler=max;
listaAlquiler=lista;
}
public Object alquilar(){
//algo que maneje la disponibilidad de alquiler
return listaAlquiler.get(0);
}
public void regresa(Object o){ //regresa el elemento alquilado
listaAlquiler.add(o);
}
}


Ahora, queremos implementar esta lógica para alquilar autos:

class Auto{}
class AlquilarAuto extends Alquilar{
public AlquilarAuto(int m,List l){
super(m,l);
}

public Object alquilar() {
return super.alquilar();
}

public void regresa(Object o) {
if (o instanceof Auto)
super.regresa(o);
else
System.err.println("Aqui no se devuelve");
}
}

Pero, si queremos usar la misma lógica para alquilar casas, uartos, computadoras? ¿tendriamos que extender siempre la misma la clase para hacer solo llamadas al
super ? Bastaría con tener una misma lógica, y dependiendo de cómo se instancie, debería de comportarse por igual, no? además no deberí haber esa validación de instanceof en el método regresa().

class
AlquilarGenerico { //de algun T ipo
private List listaAlquiler; //manejará el mismo tipo

private int maxAlquiler;

public AlquilarGenerico(int max,
List lista){ //recibe el mismo tipo con que fue instanciado
maxAlquiler=max;
listaAlquiler=lista;
}

public
T alquilar(){ //retorna el mismo Tipo
//algo que maneje la disponibilidad de alquiler
return listaAlquiler.get(0);
}

public void regresa(
T o ){ //recibe del mismo tipo que fue instanciado
listaAlquiler.add(o);
}
}



Podría haber sido cualquier letra en lugar de T, pero por convencion, se usa la letra T para referirse a los Tipos. Entonces, ya se podría usar algo así:

//...
class Auto{}
class Casa{}


public class Test2 {
public static void main(String[] args){
List autos=new ArrayList();
autos.add(new Auto());
AlquilarGenerico alquilarAuto=new AlquilarGenerico(100,autos);
Auto a1=alquilarAuto.alquilar();
alquilarAuto.regresa(a1);

List casas=new ArrayList();
casas.add(new Casa());
AlquilarGenerico alquilarCasa=new AlquilarGenerico(100,casas);
Casa c1=alquilarCasa.alquilar();
alquilarCasa.regresa(c1);

}

}

Ahora, no solo depende de cómo fue instanciado, sino también depende de cómo se llame al método. Es decir, así:


class CreateAnArrayList {

public
void makeArrayList(T t) {

List list = new ArrayList();
list.add(t); //un método nada útil, pero se conoce como influye el
}
}


Pareciera que la el método es de tipo y a la vez es un void. Pues escrito así dice que todo lo que está con será el tipo genérico. Esto se podría llamar así:

CreateAnArrayList cal=new CreateAnArrayList();
Auto a2=new Auto();
cal.makeArrayList(a2);



también podriamos restringirlo para que solo permita números

class CreateAnArrayList {

public
void makeArrayList(T t) {

List list = new ArrayList();
list.add(t);
}
}

y el bloque anterior ya no compilaría, porque a2 es un Auto y no es Number.


Ahora, también serviría como constructor de una clase.

class Radio {

public Radio(T t) { }

}

تعليقات

المشاركات الشائعة من هذه المدونة

Groovy: Un lenguaje dinámico y ágil para la Plataforma Java

Cambiar ícono a un JFrame

UML en NetBeans