{"id":31046,"date":"2024-12-09T14:25:52","date_gmt":"2024-12-09T13:25:52","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=31046"},"modified":"2024-12-09T14:29:09","modified_gmt":"2024-12-09T13:29:09","slug":"una-limitacion-de-los-tipos-genericos-en-java","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/es\/lenguajes-de-programacion\/una-limitacion-de-los-tipos-genericos-en-java\/","title":{"rendered":"Una limitaci\u00f3n de los tipos gen\u00e9ricos en Java"},"content":{"rendered":"\n

Problema<\/strong><\/h2>\n\n\n\n

Consideremos la siguiente clase Person<\/code> y las clases hijas Manager<\/code> y Employee<\/code>, definidas de la siguiente manera:<\/p>\n\n\n\n

public static class Person {
    String name;
    public Person(String name) { this.name = name; }
}

public static class Manager extends Person {
    public Manager(String name) { super(name); }
}

public static class Employee extends Person {
   public Employee(String name) { super(name); }
}
<\/code><\/pre>\n\n\n\n
Supongamos ahora un m\u00e9todo est\u00e1tico gen\u00e9rico que acepta dos par\u00e1metros de un tipo gen\u00e9rico T<\/code> y devuelve un objeto de tipo T<\/code>. Al tipo T<\/code> se le aplica la restricci\u00f3n <T extends Person><\/code>, lo que significa que T<\/code> debe tener AL MENOS todos los atributos y m\u00e9todos definidos en la clase Person<\/code>.<\/p>\n\n\n\n
Supongamos el siguiente m\u00e9todo est\u00e1tico definido de la siguiente forma:<\/p>\n\n\n\n
public static T foo(T t1, T t2) {
    \/\/ Hacer algo
    return \u2026;
}
<\/code><\/pre>\n\n\n\n
Dadas las siguientes instancias p1<\/code> y p2<\/code>, realizamos la siguiente invocaci\u00f3n del m\u00e9todo foo()<\/code>:<\/p>\n\n\n\n
Employee p1 = new Employee(\"John\");
Manager p2 = new Manager(\"Johanna\");

Person out = foo(p1, p2);
<\/code><\/pre>\n\n\n\n
\n\n\n\n
El objetivo es imponer que ambos par\u00e1metros pasados al m\u00e9todo foo()<\/code> sean del mismo tipo, de forma que el compilador genere un error si no se cumple esta condici\u00f3n.<\/strong><\/p>\n\n\n\n
Observaci\u00f3n<\/strong><\/h2>\n\n\n\n
Al ejecutar la invocaci\u00f3n del m\u00e9todo anterior, NO se genera ning\u00fan error de compilaci\u00f3n<\/strong>, ya que tanto p1<\/code> (de tipo Employee<\/code>) como p2<\/code> (de tipo Manager<\/code>) cumplen con la restricci\u00f3n impuesta al tipo gen\u00e9rico T<\/code>. Esto se debe a que ambas clases heredan los atributos de la clase Person<\/code>.<\/p>\n\n\n\n
Para entender mejor este comportamiento, es necesario analizar los mecanismos de compilaci\u00f3n y precompilaci\u00f3n del c\u00f3digo.<\/p>\n\n\n\n
El rol del type erasure<\/em><\/strong><\/h2>\n\n\n\n
El type erasure<\/strong><\/em> es el mecanismo de precompilaci\u00f3n que reemplaza todos los tipos gen\u00e9ricos por el tipo de objeto con mayor compatibilidad, respetando las restricciones impuestas.<\/p>\n\n\n\n
En este caso, como se establece la restricci\u00f3n <T extends Person><\/code>, el tipo gen\u00e9rico T<\/code> ser\u00e1 reemplazado por la clase que proporcione la mejor compatibilidad y cumpla con las restricciones impuestas. El c\u00f3digo resultante ser\u00e1:<\/p>\n\n\n\n
public static Person foo(Person t1, Person t2) {
    \/\/ Hacer algo
    return \u2026;
}
<\/code><\/pre>\n\n\n\n
Por lo tanto, se hace evidente que, cuando se realiza la invocaci\u00f3n mencionada anteriormente, tanto p1<\/code> como p2<\/code> son aceptados por el compilador, ya que ambos son “descendientes” de Person<\/code>.<\/p>\n\n\n\n
\n\n\n\n
El rol del type inference<\/em><\/strong><\/h2>\n\n\n\n
Cuando se pasan como par\u00e1metros de foo()<\/code> instancias de objetos del mismo tipo, entra en juego el mecanismo de type inference<\/em>, <\/strong>que determina qu\u00e9 clase utilizar durante la compilaci\u00f3n.<\/p>\n\n\n\n