Si dovrebbe definire un valore nullo/sconosciuto per le enumerazioni Java?

Question

quando si definisce un enum per qualcosa che può essere "indefinito" nelle interfacce, si dovrebbe

• definire un valore enum separato per questo, o
• basta usare EnumValue = null per quelle situazioni?

Ad esempio,

serviceX.setPrice (prezzo priceEnum)

enum Price { 
CHEAP, EXPENSIVE, VERRRY_EXPENSIVE, UNKNOWN 
} 

e priceEnum.UNKNOWN quando necessario

o

enum Price { 
CHEAP, EXPENSIVE, VERRRY_EXPENSIVE 
} 

e priceEnum = null quando necessaria?

Avere un piccolo dibattito su questo. Alcuni punti che ti vengono in mente:

• utilizzando Price.UNKNOWN salva un codice "if (price == null)". Puoi gestire Prezzo x tutti i valori in un singolo switch
• A seconda della tecnologia di visualizzazione, potrebbe essere più facile localizzare Price.UNKNOWN
• utilizzando il tipo Price.UNKNOWN di problema "numero magico" nel codice, IMO . Qui abbiamo Price.UNKNOWN, altrove forse Color.UNDEFINED, Height.NULLVALUE, ecc.
• utilizzando priceValue = null è più uniforme con il modo in cui altri tipi di dati vengono gestiti in Java. Abbiamo Integer i = null, DomainObject x = null, String s = null anche per valori sconosciuti, no?
• Price.UNKNOWN ti obbliga a decidere se il valore nullo è consentito per tutti i casi d'uso. Potremmo avere metodo prezzo getPrice() che può restituire Price.UNKNOWN e setPrice (Price p) che non è autorizzato ad accettare Price.UNKNOWN. Poiché Price.UNKNOWN è sempre incluso nei valori di enum, quelle interfacce appaiono un po 'sporche. So priceValue = null ha lo stesso problema (non è possibile definire nell'interfaccia se nulla è accettata o no), ma ci si sente un po 'più pulito e un po' meno fuorviante (?)

Answer 1

direi andare con Price.UNKNOWN se questo è un valore valido per un prezzo.

Sono d'accordo con gli inconvenienti di trattare riferimenti null che menzioni, e penso che motivino abbastanza la decisione.

Nuovi linguaggi, per esempio Scala (e alcuni più vecchi, Haskell) si allontanano dai riferimenti nulli tutti insieme e utilizza l'opzione/forse le monade invece ... per buoni motivi.

Answer 2

Questo è in realtà un esempio di applicazione di Null Object pattern. IMHO è sempre meglio avere un oggetto fittizio anziché null. Ad esempio, è possibile aggiungere metodi fittizi a oggetti nulli anziché distribuire il codice con controlli null ovunque. Molto conveniente.

anche il nome del enum ti dà alcune semantiche aggiuntive: è il prezzo sconosciuta, indefinita, non affidabile, non ancora noti ? E cosa significa se il prezzo è nullo?

AGGIORNAMENTO: come Aaron Digulla indica, il modello Oggetto nullo richiede memoria. Ma in realtà non è il caso per la maggior parte del tempo. Nell'implementazione tradizionale di solito si ha un singleton per l'oggetto Null utilizzato ovunque poiché non è necessario istanze separate. Diventa ancora meglio con le enumerazioni perché ottieni la semantica singleton gratuitamente.

Un altro punto è che il riferimento null e il riferimento a qualche oggetto occupano la stessa quantità di memoria (ad esempio 4 byte sulla macchina a 32 bit). È l'oggetto a cui viene fatto riferimento che occupa parte della memoria aggiuntiva. Ma se questo è un singleton, qui non c'è praticamente memoria in testa.

Answer 3

Dipende da come userai questa enumerazione. Se lo usi nelle istruzioni switch/case, non importa. Se si creano metodi nell'enumerazione, è necessario definire SCONOSCIUTO.

Per esempio è possibile definire metodo astratto public abstract Icon icon();

nella vostra enum e quindi implementare questo metodo per ogni membro del Prezzo. Probabilmente vorrai visualizzare il punto interrogativo a un prezzo sconosciuto. In questo caso basta implementare il metodo icon() che crea un'icona appropriata.

Answer 4

C'è lo Enum-Switch-Null-Trap. Quindi sembra che, proprio come con qualsiasi proprietà che sia un oggetto, se non esiste, allora è null.

Answer 5

Colore o Altezza verrebbero utilizzati nella logica del programma. Non possono gestire con un colore non definito. A Il prezzo è dato utente e potrebbe essere sconosciuto. Il colore può essere un altro utente, ma per essere usato come colore nel codice, è necessario definirli.

Quindi il prezzo può essere SCONOSO (anziché null), Colore non (null può indicare errore).