Informazioni sui generici Java. convenzioni dei parametri Tipo

Question

I nomi dei parametri tipo più comunemente usati sono:

E - Elemento (ampiamente utilizzato dal framework Java Collections)

K - Key

N - Numero

T - Type

V - Valore

S, U, V, ecc - 2 °, 3 °, 4 ° tipi

non mi sembra di capire bene cosa fa esattamente ogni lettera corrisponde a. Capisco che ogni lettera rappresenta solo una convenzione, ma cosa significa esattamente 2 °, 3 ° e 4 ° tipo? Quando dovrei usare cosa? Sul loro sito web ufficiale delle esercitazioni non fornisce ulteriori informazioni.

Answer 1

Alcuni esempi:

• Map<K, V>: Una mappa assegna solitamente V alori a K Eys. Questi sono tipi speciali di tipi, quindi sono usati qui.
• List<E>: un elenco contiene E lementi. È una convenzione che si chiamano elementi. D'altra parte, T sarebbe anche accettabile qui.
• Formatter<T>: un formattatore può formattare qualsiasi T ype.Non è davvero un elemento, né una chiave, né un valore, quindi T è la lettera corretta qui.
• Triplet<T, U, V>: Una tripletta per tipi arbitrari. Poiché la definizione del tipo non conosce nulla sui tipi che verranno compilati in seguito, utilizza solo lo T per il primo tipo, seguito dalle lettere successive in ordine alfabetico.

Answer 2

Consiglio vivamente nomi più lunghi, soprattutto quando si dispone di più di un parametro di tipo.

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

Se si insiste su una convenzione, si consiglia di aggiungere "Type" alla fine del nome, come

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

(Anche se io preferisco avere solo il nome senza suffisso. Il nome dovrebbe essere UpperCamelCase)

Answer 3

Come sapete, le lettere non significano nulla in sé e sono solo convenzioni per rendere la lettura del codice un po 'più semplice. Il "2 °, 3 ° e 4 tipi" bit significa solo quando si dispone di un tipo parametrizzato con più argomenti si dovrebbe chiamare tali argomenti S, T, U, V, ecc Per esempio

class MyClass<S, T, U> { 
} 

è una classe con tipo tre parametri.

Ovviamente non dovete usare S, T e U. Se una convenzione più significativo può essere usato allora si dovrebbe fare in modo, ad esempio

class Car<W, E, P> { 
} 

potrebbe essere una classe Car parametrizzare ruota, motore e tipo di vernice.

EDIT: Come l'altra risposta ha sottolineato, ancora meglio sarebbe:

class Car<WheelType, EngineType, PaintType> { 
} 

Answer 4

Non mi sembra di capire a cosa corrisponde esattamente ogni lettera. Capisco che ogni lettera rappresenta solo una convenzione, ma cosa significa esattamente 2 °, 3 ° e 4 ° tipo?

La ragione per cui non si "capisce esattamente a cosa corrisponde esattamente ogni lettera" è che l'uso di nomi di parametri di tipo a lettera singola è una convenzione informale. Le lettere non hanno e non possono avere significati fissi. Dovresti leggere i javadocs (e se necessario, il codice) per capire cosa significano le lettere nel contesto delle classi. Nella maggior parte dei casi, c'è un qualche tipo di significato inteso dall'autore del codice. Basta capirlo.

Quando dovrei usare cosa?

Se si sta seguendo uno standard di codifica che dice qualcosa su questo argomento, quindi fare ciò che dice. In caso contrario:

• cerco di essere coerente con le convenzioni emergenti della vostra base di codice esistente come li vedete, e
• usare il buon senso, e fare ciò che dà il codice più leggibile.

Sul loro sito Web ufficiale delle esercitazioni non fornisce ulteriori informazioni.

Che è corretto.

Il documento di guida in stile Java "ufficiale" non è stato aggiornato per ~ 10 anni. Da un lato, è un peccato che Sun/Oracle non veda più formalizzare convenzioni di stile come loro ruolo. D'altra parte, posso capire perché non lo fanno. (Non c'è "valore" per Sun, e il potenziale aggravamento per le persone coinvolte semplicemente non ne vale la pena. Se sei stato in uno di quei dibattiti inutili sul luogo "giusto" per mettere parentesi graffe, spazi e così via , e su e su, saprete cosa intendo)

Answer 5

io di solito solo rappresentano il tipo generico, come se si trattasse di un nome di classe:.

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

IMO, il codice dovrebbe essere quasi semantica al punto in cui è come leggere frasi anziché codice. Per me, questo non è molto leggibile o semantico:

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

Se tutto il resto non è sufficiente, basta chiamarlo per quello che è.