Object vs Primitive: non utilizzare long primitive perché ... il valore predefinito è zero?

Question

Object vs Primitive: non utilizzare long primitive perché ... il valore predefinito è zero?

#1 da (5 voti)
#2 da (0 voti)

0

Oggi il mio college mi ha presentato una discussione su non usare alcuni primitivi che non ho mai sentito prima. Mi piacerebbe vedere cosa ne pensate voi ragazzi.

Abbiamo una classe nel nostro progetto come:

class Order {

    private long id;
    private String name;
    // more fields
}

Abbiamo un costruttore per questa classe per tutti i campi.

Cerco sempre di usare primitive¹ invece di oggetti per memorizzare valori, solo per sfrattare la possibilità di puntatori nulli nel mezzo del mio codice, specialmente come parametri sui miei metodi. Puoi notare anche la primitiva long in questa classe.

Ma il mio college mi ha detto che preferisce usare, in questo caso, l'oggetto Long .

Il suo argomento : c'è il rischio di dimenticarsi di impostare il valore Long e il valore predefinito sarà 0 (zero), ciò che potrebbe causare alcuni problemi.

Ho apportato la modifica e non ho discusso con lui al riguardo, perché la nostra id s non inizia mai con zero, già prevenendo qualche errore nell'ottenere l'ordine errato con zero id.

Ma stavo pensando se ci fosse qualche altro problema che potrebbe essere impedito non usando la primitiva nella stessa linea della sua logica.

^{1. Sono a conoscenza della Primitive Obssession. Ma non penso che sia legato a questo argomento}

java object

posta Dherik 21.03.2018 - 19:12

fonte

2 risposte

0

Non c'è niente di sbagliato nel dire che tutti gli ID / handle validi sono positivi. Ciò ha il vantaggio che un ID / handle inizializzato di default indicherà "not set" / "not existant" senza alcun overhead. E sarà del tutto naturale supportarlo nelle API, nei formati di scambio e di output senza scrivere alcun codice aggiuntivo per la gestione di quel caso.
Nelle lingue che supportano i tipi non firmati, il tipo sottostante sarebbe unsigned per indicare che è l'unico valore speciale, ma sfortunatamente Java non lo consente.

Potresti usare un wrapper ad allocazione dinamica invece? Certo, ma perdi la naturale gestione della sentinella con un minimo sforzo extra. Inoltre, i wrapper hanno bisogno di più memoria e impongono un'ulteriore indiretta, sia che si tratti di una preoccupazione significativa per te o meno.

risposta data 21.03.2018 - 21:57

fonte

Leggi altre domande sui tag java object

I database SQL tradizionali possono essere completamente sostituiti da NewSQL? Java: accesso ai metodi dei campi degli oggetti

score 5 · Accepted Answer

Se hai bisogno di una rappresentazione per "non impostato", allora Long è una buona scelta, con null che sta per "non impostato". Se questo non è necessario, non sprecare tempo e spazio con il pugilato e l'unboxing non necessari tra long e Long .

Tuttavia, se decidi di rappresentare "non impostato", il codice cliente deve verificare quel valore speciale. Non c'è modo di evitarlo.

L'utilizzo di null è una buona scelta, poiché il codice client che dimentica quel controllo non sarà in grado di eseguire calcoli senza senso con il valore, ma fallirà rapidamente con un NullPointerException . Le eccezioni sono i tuoi amici che ti mostrano inequivocabilmente che qualcosa è andato storto. Ed è molto probabile che tu riceva un avviso in fase di compilazione per il codice client che dereferenzia un riferimento nullable.

Qualunque sia la rappresentazione "non impostata" che scegli, assicurati che non possa essere utilizzata per alcun lavoro reale, quindi mai usa 0 o -1 a tale scopo.

E, come già sottolineato da @FrankHileman nel suo commento, assicurati che solo le istanze valide escano dal tuo costruttore e non possano mai diventare non valide (ad esempio, renderle immutabili).