Comprensión de los genéricos de Java. convenciones de los parámetros de tipo

Question

Los nombres de los parámetros tipo más comúnmente utilizados son:

E - Elemento (muy utilizada por la Java Collections Framework)

K - Key

N - Número

T - Tipo

V - Valor

S, U, V etc. - 2º, 3º, 4º tipo

Parece que no entiendo exactamente qué corresponde a cada letra. Entiendo que cada letra representa solo una convención, pero ¿qué significa exactamente el 2º, 3º y 4º tipo? ¿Cuándo debería usar qué? En su sitio web oficial de tutoriales no proporciona más información.

Answer 1

Algunos ejemplos:

• Map<K, V>: Un mapa general asigna a V alores K Eys. Estos son tipos especiales de tipos, por lo que se usan aquí.
• List<E>: Una lista contiene E lements. Es una convención que se los llame elementos. Por otro lado, T también sería aceptable aquí.
• Formatter<T>: Un formateador puede formatear cualquier T ype.No es realmente un elemento, ni una clave, ni un valor, por lo que T es la letra correcta aquí.
• Triplet<T, U, V>: triplete para tipos arbitrarios. Como la definición de tipo no sabe nada sobre los tipos que se rellenarán más adelante, utiliza solo el T para el primer tipo, seguido de las siguientes letras en orden alfabético.

Answer 2

Recomiendo los nombres largos, especialmente cuando tiene más de un parámetro de tipo.

public class MyMap<Key, Value> {...} 

Si insiste en una convención, es posible que desee añadir "Tipo" al final del nombre, como

public class MyMap<KeyType, ValueType> {...} 

(aunque yo prefiero tener sólo el nombre sin sufijo. El nombre debe ser UpperCamelCase)

Answer 3

Como usted sabe, las letras no significan nada en sí mismas y son solo convenciones para facilitar la lectura del código. El "2º, 3º y 4º tipos" sólo significa poco cuando se tiene un tipo parametrizado con múltiples argumentos debe llamar a esos argumentos S, T, U, V, etc. Por ejemplo

class MyClass<S, T, U> { 
} 

es una clase con tres tipos parámetros.

Obviamente usted no tiene utilizar S, T y U. Si una convención más significativa se puede utilizar entonces debería hacerlo, por ejemplo

class Car<W, E, P> { 
} 

podría ser una clase de coches en parametrizar rueda, motor y tipo de pintura.

EDIT: Como la otra respuesta señaló, aún mejor sería:

class Car<WheelType, EngineType, PaintType> { 
} 

Answer 4

No parece entender muy bien qué hace exactamente cada letra corresponde a. Entiendo que cada letra representa solo una convención, pero ¿qué significa exactamente el 2º, 3º y 4º tipo?

La razón por la que no "entiende exactamente a qué corresponde exactamente cada letra" es que el uso de nombres de parámetros de tipo de letra única es una convención informal. Las letras no tienen y no pueden tener significados fijos. Se espera que lea los javadocs (y si es necesario, el código) para averiguar qué significan las letras en el contexto de las clases. En la mayoría de los casos, hay algún tipo de significado destinado por el autor del código. Solo descárgalo.

¿Cuándo debo usar qué?

Si usted está siguiendo un estándar de codificación que dice algo sobre este tema, a continuación, hacer lo que dice. De lo contrario:

• tratar de ser consistentes con las convenciones emergentes de su base de código existente a medida que los ve, y
• use su sentido común, y hacer lo que le da el código más legible.

En su sitio web oficial de tutoriales no proporciona más información.

Eso es correcto.

El documento "oficial" de la guía de estilo de Java no se ha actualizado durante ~ 10 años. Por un lado, es una pena que Sun/Oracle ya no vea formalizar las convenciones de estilo como su rol. Por otro lado, puedo entender por qué no lo hacen. (No hay "valor" para Sun, y el agravante potencial para las personas involucradas simplemente no vale la pena. Si has estado en uno de esos debates sin sentido sobre el lugar "correcto" para poner llaves, espacios, etc. y sigue, y sigue, usted sabrá lo que quiero decir)

Answer 5

que normalmente solo representan el tipo genérico, como si se tratara de un nombre de clase:.

abstract class DAO<Entity, Id> { 
    abstract Entity findById(Id id); 
} 

OMI, el código debe ser casi semántica hasta el punto en que es como leer oraciones en lugar de código. Para mí, esto no es muy legible o semántica:

abstract class DAO<E, I> { 
    abstract E findById(I id); 
} 

Si todo lo demás simplemente se queda corto, simplemente lo llaman lo que es.