2010-09-29 13 views
88

Ho un enum SOME_ENUM:enum.values ​​() - è un ordine di enumerazioni restituiti deterministico

public enum SOME_ENUM { 
    EN_ONE, 
    EN_TWO, 
    EN_THREE; 
} 

Will SOME_ENUM.values() ritornano sempre le enumerazioni nell'ordine delle dichiarazioni enum: EN_ONE, EN_TWO, EN_THREE? È una regola o non è garantito che non venga modificata nelle prossime versioni di JDK?

+1

perché dovresti fare affidamento su di esso? –

+1

I iterate sul mio enum per riempire una lista, che in un altro posto nel codice che ho letto ripetendo questo enum. – Skarab

+11

@MitchWheat Per la stessa ragione per cui si farebbe affidamento su un ordine di conservazione di List: perché JDK è uno strumento che ti dà certe garanzie e fare affidamento su queste garanzie ti aiuta a scrivere codice più succinto e migliore. Certo, la domanda "è garantito che non si cambi?" è impossibile rispondere, non puoi certo fidarti di questo, nulla ha questa garanzia. – Fletch

risposta

126

La specifica del linguaggio Java utilizza questo linguaggio esplicito:

@return un array contenente le costanti di questo tipo enum, nell'ordine in cui sono dichiarati [Source]

Quindi, sì , saranno restituiti in ordine di dichiarazione. Vale la pena notare che l'ordine potrebbe cambiare nel tempo se qualcuno cambia classe, quindi stai molto attento a come lo usi.

+1

Se qualcuno aggiunge un valore nel mezzo in una versione successiva del codice, questo potrebbe ridurlo, poiché cambierebbe il valore ordinale di altri elementi (vedere il metodo Enum.ordinal()). È meglio non fare affidamento sulla posizione ordinale come meccanismo di serializzazione (cioè, non memorizzarlo nel db) per questo motivo. – Matt

+1

Collegamento all'origine per tale specifica? – screenmutt

+0

[Java 8 doc] (http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.9.3) –

14

Sì, è garantito restituirli in questo ordine.

Tuttavia, è consigliabile evitare di fare affidamento su di esso e sul valore ordinal(), poiché può cambiare dopo l'inserimento di nuovi elementi, ad esempio.

+0

+1 per il consiglio di saggio.Sull'argomento di ordinale(), Java efficace suggerisce di aggiungere un campo membro al tipo enum. – ide

9

è determinato dall'ordine i valori vengono dichiarati. Tuttavia, non v'è alcuna garanzia che voi (o qualcun altro) non sarà riordinare/estrazione/inserimento valori in futuro. Quindi non dovresti fare affidamento sull'ordine.

Java efficace 2 °. Edizione dedica la sua voce 31 ad un argomento strettamente correlato: Utilizzare i campi di istanza al posto dei numeri ordinali:

Mai derivare un valore associato a un enum dalla sua ordinale; memorizzarlo invece in un campo istanza.

+3

"non garantisce che qualcuno non riordini i valori in futuro" - ma è esattamente il motivo per cui voglio fare affidamento sull'ordine :-)! Voglio poter riordinare gli articoli in futuro e quindi modificare il comportamento del mio programma. Bloch ha ragione nel non fare affidamento sull'ordinale e se l'esempio del richiedente richiede davvero enum come EN_TWO, allora si affida all'ordinale e non dovrebbe farlo. Ma affidarsi all'ordine è perfetto. Infatti, siccome l'ordine è garantito, creare un campo specifico per l'ordine sarebbe scrivere codice ridondante, il tipo di libri di cose come Java efficace ti dicono di non farlo. – Fletch

+0

@Fletch, mi dispiace, non ti seguo abbastanza. A me sembra che tu stia cercando di usare 'enum' per qualche scopo per il quale non è stato concepito. –

+0

diciamo che hai il famoso enum "Pianeta". Nella tua interfaccia utente desideri elencare i pianeti nell'ordine della loro distanza dal sole. Come puoi accettarlo al meglio? Ordinerei le costanti del pianeta nell'ordine corretto all'interno della classe enum e quindi enumeri l'enum nell'interfaccia utente. Poiché l'ordine è affidabile, funzionerà. Questo è il tipo di cosa di cui sto parlando. Se un giorno la Terra si avvicina al Sole più di Marte, ovviamente in un momento del genere la prima cosa sulla tua mente calda manterrà il tuo codice! Quindi vai alla tua classe Planet e muovi TERRA prima di MARS. – Fletch

7

Le altre risposte sono buone, ma non commento su questo: "E 'una regola o non è garantito di non essere cambiato nel prossimo Jdk rilascia"

Non credo che esistano garanzie sui futuri JDK, quindi non dovresti nemmeno preoccuparti di loro. Non ci sarebbe modo di farli rispettare, i futuri conduttori di JDK potrebbero decidere di rinunciare a tali garanzie. È come il sistema parlamentare di Westminster: "Nessun Parlamento può legare un futuro parlamento".

Detto questo, la storia del JDK rivela un'eccellente coerenza. Non apportano molti cambiamenti irrisolti, quindi puoi essere abbastanza sicuro che il comportamento corrente specificato (non appena osservato) verrà mantenuto.

Problemi correlati