I campi devono essere esplicitamente definitivi per avere un oggetto "corretto" immutabile?

Question

Spesso si legge di oggetti immutabili che richiedono che i campi finali siano immutabili in Java. È questo il caso, o è semplicemente sufficiente per non avere mutabilità pubblica e non mutare effettivamente lo stato?

Ad esempio, se si dispone di un oggetto immutabile creato dal modello di builder, è possibile farlo assegnando al builder i singoli campi mentre vengono creati, oppure mantenendo il campo stesso e restituendo infine l'oggetto immutabile passando i valori al suo costruttore (privato).

Avere i campi finali ha l'ovvio vantaggio di impedire errori di implementazione (come ad esempio consentire al codice di conservare un riferimento al builder e "costruire" l'oggetto più volte mentre in realtà muta un oggetto esistente), ma avendo l'archivio Builder i suoi dati all'interno dell'oggetto così come sono costruiti sembrano essere DRYer.

Quindi la domanda è: supponendo che il Builder non perda l'oggetto in anticipo e si fermi da modificare l'oggetto una volta costruito (ad esempio impostando il suo riferimento all'oggetto come null) ci sia effettivamente qualcosa ottenuto (come una migliore sicurezza del thread) nella "immutabilità" dell'oggetto se invece i campi dell'oggetto sono stati resi definitivi?

Answer 1

Sì, si ottiene "sicurezza filo" dai campi final. Vale a dire, il valore assegnato a un campo final durante la costruzione è garantito per essere visibile a tutti i thread. L'altra alternativa per la sicurezza delle filettature è dichiarare i campi volatile, ma in questo caso si incorre in un sovraccarico elevato con ogni lettura & hellip; e confondere chiunque guarda la tua classe e si chiede perché i campi di questa classe "immutabile" sono contrassegnati come "volatili".

Contrassegnare i campi final è il più corretto tecnicamente e trasmette il tuo intento in modo più chiaro. Sfortunatamente, rende molto complicato il modello di builder. Penso che dovrebbe essere possibile creare un processore di annotazione per sintetizzare un costruttore per una classe immutabile, proprio come fa Project Lombok con setter e getter. Il vero lavoro sarebbe il supporto IDE necessario per poter codificare i costruttori che non esistono realmente.

Answer 2

Un oggetto può certamente avere campi privati ​​mutabili e funziona ancora come un oggetto immutabile. Tutto ciò che conta per soddisfare il contratto di immutabilità è che l'oggetto appare immutabile dall'esterno. Un oggetto con campi privati ​​non finali, ma nessun setter, ad esempio, soddisferà questo requisito.

Infatti, se il tuo incapsulamento è corretto, puoi effettivamente mutare lo stato interno e continuare a funzionare correttamente come un oggetto "immutabile". Un esempio potrebbe essere una sorta di valutazione pigra o memorizzazione nella cache delle strutture di dati.

Clojure ad esempio esegue questa implementazione interna di sequenze lazy, questi oggetti si comportano come se fossero immutabili ma solo in realtà calcolano e memorizzano i valori futuri quando vengono richiesti direttamente. Qualsiasi richiesta successiva recupera il valore memorizzato.

Tuttavia, aggiungerei come un avvertimento che il numero di luoghi in cui si vorrebbe effettivamente modificare l'interno di un oggetto immutabile è probabilmente piuttosto raro. In caso di dubbio, rendili definitivi.

Answer 3

Penso che dovresti solo considerare l'ambiente in cui è in esecuzione e decidere se i quadri che usano la riflessione per manipolare gli oggetti sono un pericolo.

Uno potrebbe facilmente creare uno scenario strano in cui un oggetto apparentemente immutabile viene danneggiato da un attacco di iniezione POST a causa di un framework di associazione Web configurato per l'uso di reflection anziché di bean setter.

Answer 4

Si può sicuramente avere un oggetto immutabile con campi non finali.

Ad esempio, vedere l'implementazione java 1.6 di java.lang.String.

Answer 5

Commento: @erickson

Come quella:

 
class X { volatile int i, j; } 
X y; 

// thread A: 
X x = new X; 
x.i = 1; 
x.j = 2; 
y = x; 

// thread B: 
if (y != null) { 
    a = y.i; 
    b = y.j; 
} 

?