JavaRush /Java Blog /Random-IT /Getter e incapsulamento rotto
Vadelic
Livello 14
Пасадена

Getter e incapsulamento rotto

Pubblicato nel gruppo Random-IT
Durante la risoluzione dei problemi, ho riscontrato un comportamento inaspettato dei getter. Nelle lezioni qui e anche nei getter generati da IntelliJ IDEA, viene utilizzato lo schema più semplice: public final class A { private A field; public A getField() { return field; } public void setField(A field) { this.field = field; } } se il campo è un tipo primitivo o String, che viene passato per valore, allora va tutto bene, ma se l'oggetto viene passato per riferimento, poi si scopre che attraverso il getter è possibile ottenere l'accesso completo al campo, il che annulla il livello di accesso protetto impostato. Se il setter contiene una condizione di validità, allora può essere aggirato tramite un tale getter, che viola l'incapsulamento e sarebbe corretto creare un clone dell'oggetto per evitare questo problema. Capisco che non tutti gli oggetti possono essere facilmente clonati, e se questo è lasciato alla responsabilità del programmatore, allora è strano perché non ne sia stato menzionato da nessuna parte nelle lezioni. UPD: Un getter, come idea, ovviamente, non viola l'incapsulamento, ma deve essere scritto in modo tale da non tradire i principi dell'OOP. Ciò significa che se un getter produce un oggetto, lo fa in modo tale che l'utente non possa modificarlo in nessun altro modo specificato nella classe. Esiste un metodo meraviglioso nella classe Collections che produce una raccolta di sola lettura. Ciò impone una serie di altre restrizioni, ad esempio l'impossibilità di ordinare, ma in questo caso questa classe ha: immodificabileSortedSet immodificabileSortedMap e alcuni altri, per maggiore comodità. public static Collection unmodifiableCollection(Collection c)
Commenti
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION