Perché il metodo getter e setter è importante in java?

Mi è stato insegnato a usare sempre getter e setter. Tuttavia, non conosco i pro e i contro di questi metodi, poiché implementandoli stiamo esponendo i dati e nascondendoli.

Sono un po ‘confuso su questo. Qualcuno può dare qualche consiglio sul perché usiamo un getter / setter e quali sono i vantaggi?

Il campo base “campo privato con getter pubblico e setter che non fanno altro che restituire o impostare il modello” del campo è davvero completamente inutile quando si parla di incapsulamento, tranne che ti dà la possibilità di cambiarlo in seguito senza cambiare l’API.

Quindi non usare quel modello senza pensarci. Considerare attentamente quali operazioni sono effettivamente necessarie.

Il vero punto di arrivo di getter e setter è che dovresti usarli solo dove sono appropriati e che possono fare di più che ottenere e impostare i campi.

  • Puoi avere solo un getter. Quindi la proprietà è di sola lettura. Questo dovrebbe essere il caso più comune.
  • Puoi avere solo un setter, rendendo la proprietà configurabile, ma comunicando che nient’altro dovrebbe dipendere dal suo valore
  • Un getter può calcolare un valore da diversi campi piuttosto che restituire un campo.
  • Un getter può fare una copia difensiva
  • Un getter può eseguire pochissimo un’operazione di recupero costoso e utilizzare un campo per memorizzare il valore nella cache
  • Un setter può eseguire controlli di IllegalArgumentException e lanciare IllegalArgumentException
  • Un setter può notificare agli ascoltatori le modifiche al valore
  • Puoi avere un setter che imposta insieme più campi perché appartengono concettualmente. Questo non rispetta le specifiche JavaBeans, quindi non farlo se si dipende da framework o strumenti che si aspettano JavaBeans. Altrimenti, è un’opzione utile.

Tutte queste cose sono dettagli di implementazione nascosti dietro la semplice interfaccia “getter and setter”. Questo è l’incapsulamento.

L’idea di getter e setter è controllare l’accesso alle variabili in una class. In questo modo, se il valore deve essere modificato internamente per essere rappresentato in un modo diverso, puoi farlo senza violare alcun codice al di fuori della class.

Ad esempio, supponiamo che tu avessi una class con una variabile di distanza ed è stata misurata in pollici. Passano alcuni mesi, stai usando questa class in molti posti e all’improvviso ti rendi conto che dovevi rappresentare quel valore in centimetri. Se non hai usato un getter e un setter, dovresti rintracciare ogni uso della class e convertire lì. Se hai usato un getter e un setter, puoi semplicemente cambiare quei metodi e tutto ciò che usa la class non si romperà.

 public class Measurement { /** * The distance in centimeters. */ private double distance; /** * Gets the distance in inches. * @return A distance value. */ public double getDistance() { return distance / 2.54; } /** * Sets the distance. * @param distance The distance, in inches. */ public void setDistance(double distance) { this.distance = distance * 2.54; } } 

Un buon vantaggio viene in mente è che puoi creare un campo ReadOnly non implementando un setter per quel particolare campo.

Non c’è niente di sbagliato nell’usare getter e setter: devi solo essere consapevole che usandoli e rendendoli tutti pubblici stai esponendo le tue variabili e, in un certo senso, violando l’incapsulamento. Questo è ciò che l’articolo che hai citato sta cercando di mettere in guardia: non generare automaticamente getter e setter per tutte le variabili di istanza private; pensa a ciò che vuoi esporre ad altre classi (ea quale livello, cioè privato / protetto / pubblico) in modo da esporlo solo se necessario.

Ecco il rovescio della medaglia. I getter / setter tendono ad esporre i dettagli di implementazione della tua class al mondo esterno. Questa non è una buona cosa Immagina di scrivere un pacchetto software Auto meccanico. Quindi avrai bisogno di una class Car, e quindi esponi getter e setter per i campi

 Date lastOilChangeDate; int lastOilChangeMileage; 

in questa class. Questo perché il software vuole inviare e-mail quando le auto dei clienti hanno bisogno di cambi di olio.

Ma cosa succede quando escono nuove macchine dove si determina se una macchina ha bisogno di un cambio dell’olio diverso da “ogni 3000 miglia o 3 mesi”? Forse queste nuove auto hanno un sensore nella coppa dell’olio che ha misurato lo sporco. Ovviamente vorresti usarlo per determinare se fosse necessario un cambio d’olio.

Il problema era che stavi risolvendo il problema sbagliato con quei getter / setter. Nessuno vuole davvero sapere quando è stato l’ultimo cambio di petrolio, vogliono sapere se ne hai bisogno di un altro. Erano solo dettagli di implementazione, ma li hai resi parte dell’interfaccia. Quello che avresti dovuto fare è stato aggiungere un metodo

 public boolean needsOilChange() 

e poi la class Car potrebbe implementare comunque voluta. Se l’algoritmo cambia, la class Mechanic non dovrebbe farlo perché tutto ciò di cui aveva bisogno era il metodo needOilChange.

questo è principalmente usato nei bean Java come sotto.

public Class MyBean{

private int var1;

public void setVar1(int pVar1){

this.var1=pvar1;

}

public int getVar1(){

return var1; `

}

}

i benefici sono come sotto

1. Con questo possiamo ottenere Incapsulamento

2. è chiamato DTO (Data Transfer Object) modello di progettazione. viene utilizzato per trasferire i dati da un livello a un altro in applicazioni basate su MVC. come se tu potessi ottenere dati inseriti dall’utente dal form (usando getter) e puoi usare gli stessi dati da inserire nel database (usando setter) e vice verca. ultimi framework (SPring) che forniscono funzionalità incorporate.