2011-10-28 3 views
11

Questo è più di un seguito alle domande 1 & 2.Problemi di findbug con la mutabilità dell'oggetto Date in Java

come detto nelle questioni il codice qui sotto

public Date getSomeDate() { 
    return someDate; 
} 

vi darà l'errore findbug issue.

La soluzione suggerita è stato quello di duplicare l'oggetto Date in entrambi i getter e setter come

public Date getSomeDate() { 
    return new Date(someDate.getTime()); 
} 

'questo un buon approccio o ci sono modi alternativi per questo?

Esiste una libreria di Date immutable disponibile in Java che possa risolvere questo problema?

+0

Cercavi giusto immutabili? comunque, l'approccio dichiarato è perfetto. –

+0

@PrinceJohnWesley: grazie e sì. Ho aggiornato la Qs. Vuoi dire che è giusto usare il costruttore Date in tutti i getter e setter? – ManuPK

+0

Finché non esporre le chiamate alla libreria esterna. non hai bisogno di clonare in profondità (costruttore) perché sai cosa fai. Altrimenti indica sempre il riferimento alla differenza se è mutabile. Prova joda time api –

risposta

6

JodaTime ha date immutabili.

Certo, va bene usare un costruttore Date in un getter, perché non dovrebbe essere?

Detto questo, solo perché lo stato mutabile di FindBugs peg come un potenziale errore, non significa che sia intrinsecamente degno di attenzione su – dipende da come viene utilizzata la classe. L'immutabilità elimina un tipo di bug, di cui potresti o non dovresti preoccuparti molto.

0

A seconda del caso di utilizzo, è possibile restituire someDate.getTime() senza avvolgerlo in un Date.

0

Aspetta un minuto ... copiando l'oggetto entro i getSomeDate e setSomeDate metodi non stiamo eliminando il rischio per la sicurezza in quanto l'oggetto modificato ritorna attraverso il setSomeDate e copie preservare i valori modificati. Sarebbe necessario rimuovere setSomeDate per risolvere questo tipo di problema di sicurezza, o non preoccuparti affatto.

+2

Restituendo una copia dell'oggetto, evitiamo che la rappresentazione interna sia condivisa: aiuterà a evitare situazioni in cui il codice chiamante (anche se riceve questa proprietà su una variabile locale) lo manipola, la proprietà bean sarà cambiato. Per affermare l'ovvio, setomeDate non può essere rimosso poiché questo è il comportamento dei bean fondamentali. – emeralddove

7

Attenzione Folks ...

oltre adattare sia il getter e setter è necessario prendere a cuore i valori nulli:

public Date getSomeDate() { 
    if (this.someDate == null) { 
    return null; 
    } 
    return new Date(this.someDate.getTime()); 
} 

public void setSomeDate(final Date someDate) { 
    if (someDate == null) { 
    this.someDate = null; 
    } else{ 
    this.someDate = new Date(someDate.getTime()); 
    } 
}