objeto - nodo generico java

Genéricos en Java

Question

¿Hay alguna manera taquigráfica de definir y usar definaciones genéricas sin tener que seguir repitiendo una descripción genérica particular de modo que si hay un cambio no tengo que cambiar todas las definaciones / usos aunque la base de código por ejemplo es algo como esto posible:

Typedef myGenDef = < Object1, Object2 >;

HashMap< myGenDef > hm = new HashMap< myGenDef >();

for (Entry< myGenDef > ent : hm..entrySet())
{
.
.
.
}

Answer 1

En un método genérico, puede usar una forma limitada de inferrence de tipo para evitar algunas repeticiones.

Ejemplo: si tienes la función

    <K, V> Map<K, V> getSomething() {
        //...
    }

puedes usar:

final Map<String, Object> something = getsomething();

en lugar de:

final Map<String, Object> something = this.<String, Object>getsomething();

Answer 2

No. Aunque, groovy, un lenguaje JVM, se escribe de forma dinámica y te permite escribir:

def map = new HashMap<complicated generic expression>();

Answer 3

Use Factory Pattern para la creación de Generics:

Muestra de método:

public Map<String, Integer> createGenMap(){
        return new HashMap<String,Integer>();

    }

Answer 4

El antipatrón pseudo-typedef mencionado por Shog9 funcionaría, aunque no se recomienda usar ANTIPATTERN, pero no aborda sus intenciones. El objetivo de pseudo-typedef es reducir el desorden en la declaración y mejorar la legibilidad.

Lo que quiere es poder reemplazar un grupo de declaraciones de genéricos por una sola operación. Creo que tienes que parar y pensar: "¿De qué forma es valioso?". Quiero decir, no puedo pensar en un escenario donde necesitarías esto. Imagina la clase A:

class A {
     private Map<String, Integer> values = new HashMap<String, Integer>();
}

Imagine ahora que quiero cambiar el campo ''valores'' a un Mapa. ¿Por qué existirían muchos otros campos diseminados a través del código que necesita el mismo cambio? En cuanto a las operaciones que usan ''valores'', una simple refactorización sería suficiente.

Answer 5

Está el antipatrón pseudo-typedef ...

class StringList extends ArrayList<String> { }

¡Buenas cosas, beber! ;-)

Como se señala en el artículo, esta técnica tiene algunos problemas serios, principalmente que este "typedef" es en realidad una clase separada y, por lo tanto, no puede usarse indistintamente con el tipo que se extiende u otros tipos definidos de manera similar.