Perché usare getter e setter / accessori?

Qual è il vantaggio di usare getter e setter - che ottengono e impostano - invece di usare semplicemente campi pubblici per quelle variabili?

Se getter e setter stanno facendo qualcosa di più del semplice get / set, posso capirlo molto rapidamente, ma non sono chiaro al 100% su come:

public String foo;

è peggio di:

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

Considerando che il primo prende molto meno codice del boilerplate.

In realtà ci sono molte buone ragioni per considerare l'uso degli accessor piuttosto che esporre direttamente i campi di una classe - oltre all'argomento dell'incapsulamento e rendendo più facili i cambiamenti futuri.

Ecco alcuni dei motivi di cui sono a conoscenza:

• Incapsulamento del comportamento associato all'ottenimento o all'impostazione della proprietà: ciò consente di aggiungere più facilmente funzionalità aggiuntive (come la convalida) in un secondo momento.
• Nascondere la rappresentazione interna della proprietà mentre si espone una proprietà utilizzando una rappresentazione alternativa.
• Isolare l'interfaccia pubblica dal cambiamento - consentendo all'interfaccia pubblica di rimanere costante mentre l'implementazione cambia senza influire sui consumatori esistenti.
• Controllo della semantica della gestione della vita e della memoria (smaltimento) della proprietà, particolarmente importante negli ambienti di memoria non gestiti (come C ++ o Objective-C).
• Fornire un punto di intercettazione di debug per quando una proprietà cambia in fase di esecuzione - il debug quando e dove una proprietà è cambiata in un determinato valore può essere abbastanza difficile senza questo in alcune lingue.
• Interoperabilità migliorata con le librerie progettate per operare contro getter / setter di proprietà: vengono in mente derisione, serializzazione e WPF.
• Consentire agli eredi di modificare la semantica di come la proprietà si comporta e viene esposta sostituendo i metodi getter / setter.
• Consentire al getter / setter di essere passato come espressioni lambda anziché come valori.
• Getter e setter possono consentire diversi livelli di accesso, ad esempio il get potrebbe essere pubblico, ma il set potrebbe essere protetto.

Perché tra 2 settimane (mesi, anni) da quando ti rendi conto che il tuo setter deve fare di più che semplicemente impostare il valore, ti accorgerai anche che la proprietà è stata utilizzata direttamente in altre 238 classi :-)

Un campo pubblico non è peggio di una coppia getter / setter che non fa altro che restituire il campo e assegnarlo. Innanzitutto, è chiaro che (nella maggior parte delle lingue) non esiste alcuna differenza funzionale. Qualsiasi differenza deve essere in altri fattori, come la manutenibilità o la leggibilità.

Un vantaggio spesso menzionato delle coppie getter / setter non lo è. C'è questa affermazione che puoi cambiare l'implementazione e che i tuoi clienti non devono essere ricompilati. Presumibilmente, i setter ti consentono di aggiungere funzionalità come la convalida in un secondo momento e i tuoi clienti non hanno nemmeno bisogno di saperlo. Tuttavia, l'aggiunta di convalida a un setter è una modifica delle sue condizioni preliminari, una violazione del contratto precedente , che era, semplicemente, "puoi inserire qualsiasi cosa qui e puoi ottenere la stessa cosa in seguito dal getter".

Quindi, ora che hai rotto il contratto, cambiare ogni file nella base di codice è qualcosa che dovresti voler fare, non evitare. Se lo eviti, stai assumendo che tutto il codice presupponesse che il contratto per quei metodi fosse diverso.

Se quello non avrebbe dovuto essere il contratto, allora l'interfaccia consentiva ai client di mettere l'oggetto in stati non validi. È esattamente l'opposto dell'incapsulamento Se quel campo non poteva davvero essere impostato su niente dall'inizio, perché la validazione non è stata fin dall'inizio?

Lo stesso argomento si applica ad altri presunti vantaggi di queste coppie getter / setter pass-through: se in seguito si decide di modificare il valore impostato, si infrange il contratto. Se si sovrascrive la funzionalità predefinita in una classe derivata, al di là di alcune modifiche innocue (come la registrazione o altri comportamenti non osservabili), si infrange il contratto della classe base. Questa è una violazione del Principio di sostituibilità di Liskov, che è visto come uno dei principi di OO.

Se una classe ha questi getter e setter stupidi per ogni campo, allora è una classe che non ha invarianti di sorta, nessun contratto . È davvero un design orientato agli oggetti? Se tutta la classe ha quei getter e setter, è solo un detentore di dati stupido, e i detentori di dati stupidi dovrebbero apparire come detentori di dati stupidi:

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

L'aggiunta di coppie getter / setter pass-through a tale classe non aggiunge alcun valore. Altre classi dovrebbero fornire operazioni significative, non solo operazioni già fornite dai campi. Ecco come puoi definire e mantenere utili invarianti.

Cliente : "Cosa posso fare con un oggetto di questa classe?"
Designer : "Puoi leggere e scrivere diverse variabili".
Cliente : "Oh ... figo, immagino?"

Ci sono ragioni per usare getter e setter, ma se tali ragioni non esistono, creare coppie getter / setter in nome di falsi dei incapsulati non è una buona cosa. I motivi validi per rendere getter o setter includono le cose spesso menzionate come potenziali modifiche che è possibile apportare in seguito, come la convalida o diverse rappresentazioni interne. O forse il valore dovrebbe essere leggibile dai clienti ma non scrivibile (ad esempio, leggere le dimensioni di un dizionario), quindi un semplice getter è una buona scelta. Ma quelle ragioni dovrebbero essere lì quando fai la scelta, e non solo come una cosa potenziale che potresti desiderare in seguito. Questa è un'istanza di YAGNI ( non ne avrai bisogno ).

Molte persone parlano dei vantaggi di getter e setter, ma io voglio interpretare l'avvocato del diavolo. In questo momento sto eseguendo il debug di un programma molto grande in cui i programmatori hanno deciso di fare tutto getter e setter. Potrebbe sembrare carino, ma è un incubo di reverse engineering.

Supponiamo che tu stia esaminando centinaia di righe di codice e ti imbatti in questo:

person.name = "Joe";

È un pezzo di codice meravigliosamente semplicemente finché non ti rendi conto che è un setter. Ora segui quel setter e scopri che imposta anche person.firstName, person.lastName, person.isHuman, person.hasReallyCommonFirstName e chiama person.update (), che invia una query al database, ecc. Oh, questo è dove si stava verificando la perdita di memoria.

Capire a prima vista un pezzo di codice locale è una proprietà importante di buona leggibilità che tenditori e setter tendono a rompere. Questo è il motivo per cui provo a evitarli quando posso e minimizzo quello che fanno quando li uso.

Ci sono molte ragioni. Il mio preferito è quando è necessario modificare il comportamento o regolare ciò che è possibile impostare su una variabile. Ad esempio, supponiamo che tu abbia un metodo setSpeed ​​(int speed). Ma vuoi che puoi impostare solo una velocità massima di 100. Faresti qualcosa del tipo:

public void setSpeed(int speed) {
  if ( speed > 100 ) {
    this.speed = 100;
  } else {
    this.speed = speed;
  }
}

Ora cosa succede se OVUNQUE nel tuo codice stavi utilizzando il campo pubblico e ti rendessi conto di aver bisogno dei requisiti di cui sopra? Divertiti a cercare ogni utilizzo del campo pubblico invece di modificare il tuo setter.

I miei 2 centesimi :)

In un puro mondo orientato agli oggetti, getter e setter è un terribile anti-schema . Leggi questo articolo: Getter / setter. Il male. Periodo . In breve, incoraggiano i programmatori a pensare agli oggetti come a strutture di dati, e questo tipo di pensiero è puro procedurale (come in COBOL o C). In un linguaggio orientato agli oggetti non ci sono strutture di dati, ma solo oggetti che espongono comportamenti (non attributi / proprietà!)

Puoi trovare ulteriori informazioni al riguardo nella Sezione 3.5 di Elegant Objects (il mio libro sulla programmazione orientata agli oggetti).

Un vantaggio di accessori e mutatori è che è possibile eseguire la convalida.

Ad esempio, se foofosse pubblico, potrei facilmente impostarlo su nulle quindi qualcun altro potrebbe provare a chiamare un metodo sull'oggetto. Ma non c'è più! Con un setFoometodo, ho potuto garantire che foonon fosse mai stato impostato null.

Gli accessori e i mutatori consentono anche l'incapsulamento: se non dovresti vedere il valore una volta impostato (forse è impostato nel costruttore e quindi utilizzato dai metodi, ma non dovrebbe mai essere modificato), non sarà mai visto da nessuno. Ma se puoi consentire ad altre classi di vederlo o modificarlo, puoi fornire l'accessorio e / o il mutatore corretti.

Dipende dalla tua lingua. Hai taggato questo "orientato agli oggetti" piuttosto che "Java", quindi vorrei sottolineare che la risposta di ChssPly76 dipende dalla lingua. In Python, ad esempio, non c'è motivo di usare getter e setter. Se è necessario modificare il comportamento, è possibile utilizzare una proprietà, che avvolge un getter e un setter attorno all'accesso agli attributi di base. Qualcosa come questo:

class Simple(object):
   def _get_value(self):
       return self._value -1

   def _set_value(self, new_value):
       self._value = new_value + 1

   def _del_value(self):
       self.old_values.append(self._value)
       del self._value

   value = property(_get_value, _set_value, _del_value)

Bene, voglio solo aggiungere che anche se a volte sono necessari per l'incapsulamento e la sicurezza delle variabili / oggetti, se vogliamo codificare un vero programma orientato agli oggetti, allora dobbiamo smettere di sovraccaricare gli accessori , perché a volte dipendiamo molto su di loro quando non è realmente necessario e ciò rende quasi lo stesso come se rendessimo pubbliche le variabili.

Grazie, questo ha chiarito davvero il mio pensiero. Ora ecco (quasi) 10 (quasi) buoni motivi per NON usare getter e setter:

1. Quando ti rendi conto che devi fare molto di più che impostare e ottenere il valore, puoi semplicemente rendere il campo privato, il che ti dirà immediatamente dove hai avuto accesso direttamente.
   
2. Qualsiasi convalida che esegui lì può essere solo libera dal contesto, la cui convalida raramente è in pratica.
   
3. Puoi cambiare il valore impostato - questo è un incubo assoluto quando il chiamante ti passa un valore che [shock horror] vuole che tu memorizzi COSÌ COM'È.
   
4. Puoi nascondere la rappresentazione interna - fantastica, quindi ti stai assicurando che tutte queste operazioni siano simmetriche, giusto?
   
5. Hai isolato la tua interfaccia pubblica dalle modifiche sotto i fogli: se stavi progettando un'interfaccia e non eri sicuro che l'accesso diretto a qualcosa fosse OK, allora avresti dovuto continuare a progettare.
   
6. Alcune biblioteche si aspettano questo, ma non molte: riflessione, serializzazione, oggetti finti funzionano perfettamente con i campi pubblici.
   
7. Ereditando questa classe, puoi sovrascrivere la funzionalità di default - in altre parole puoi VERAMENTE confondere i chiamanti non solo nascondendo l'implementazione ma rendendola incoerente.
   

Gli ultimi tre che sto per lasciare (N / A o D / C) ...

So che è un po 'tardi, ma penso che ci siano alcune persone interessate alla performance.

Ho fatto un piccolo test delle prestazioni. Ho scritto una classe "NumberHolder" che, bene, contiene un numero intero. Puoi leggere quel numero intero usando il metodo getter anInstance.getNumber()o accedendo direttamente al numero usando anInstance.number. Il mio programma legge il numero 1.000.000.000 di volte, in entrambi i modi. Tale processo viene ripetuto cinque volte e il tempo viene stampato. Ho il seguente risultato:

Time 1: 953ms, Time 2: 741ms
Time 1: 655ms, Time 2: 743ms
Time 1: 656ms, Time 2: 634ms
Time 1: 637ms, Time 2: 629ms
Time 1: 633ms, Time 2: 625ms

(Il tempo 1 è il modo diretto, il tempo 2 è il getter)

Vedi, il getter è (quasi) sempre un po 'più veloce. Quindi ho provato con diversi numeri di cicli. Invece di 1 milione, ho usato 10 milioni e 0,1 milioni. I risultati:

10 milioni di cicli:

Time 1: 6382ms, Time 2: 6351ms
Time 1: 6363ms, Time 2: 6351ms
Time 1: 6350ms, Time 2: 6363ms
Time 1: 6353ms, Time 2: 6357ms
Time 1: 6348ms, Time 2: 6354ms

Con 10 milioni di cicli, i tempi sono quasi gli stessi. Ecco 100 mila (0,1 milioni) di cicli:

Time 1: 77ms, Time 2: 73ms
Time 1: 94ms, Time 2: 65ms
Time 1: 67ms, Time 2: 63ms
Time 1: 65ms, Time 2: 65ms
Time 1: 66ms, Time 2: 63ms

Anche con diverse quantità di cicli, il getter è un po 'più veloce del normale. Spero che questo ti abbia aiutato.

Non utilizzare setter Getter se non necessario per la consegna corrente. Vale a dire non pensare troppo a ciò che potrebbe accadere in futuro, se qualcosa da cambiare è una richiesta di modifica nella maggior parte delle applicazioni di produzione, sistemi.

Pensa semplice, facile, aggiungi complessità quando necessario.

Non approfitterei dell'ignoranza dei proprietari di attività di profondo know-how tecnico solo perché penso che sia corretto o mi piace l'approccio.

Ho un sistema enorme scritto senza setter di getter solo con modificatori di accesso e alcuni metodi per convalidare n eseguire la logica biz. Se hai assolutamente bisogno di. Usa qualsiasi cosa.

Usiamo getter e setter:

• per riusabilità
• eseguire la convalida nelle fasi successive della programmazione

I metodi getter e setter sono interfacce pubbliche per accedere ai membri della classe privata.

Mantra dell'incapsulamento

Il mantra dell'incapsulamento è rendere i campi privati ​​e metodi pubblici.

Metodi Getter: possiamo ottenere l'accesso a variabili private.

Metodi setter: possiamo modificare campi privati.

Anche se i metodi getter e setter non aggiungono nuove funzionalità, possiamo cambiare idea tornando più tardi per rendere quel metodo

• meglio;
• più sicuro; e
• Più veloce.

Ovunque è possibile utilizzare un valore, è possibile aggiungere un metodo che restituisce quel valore. Invece di:

int x = 1000 - 500

uso

int x = 1000 - class_name.getValue();

In parole povere

Supponiamo di dover memorizzare i dettagli di questo Person. Questo Personha i campi name, agee sex. In questo modo si comporta la creazione di metodi per name, agee sex. Ora, se abbiamo bisogno di creare un'altra persona, diventa necessario creare i metodi per name,age , sextutto da capo.

Invece di farlo, possiamo creare un bean class(Person)con metodi getter e setter. Quindi domani possiamo semplicemente creare oggetti di questo fagiolo class(Person class)ogni volta che dobbiamo aggiungere una nuova persona (vedere la figura). Quindi stiamo riutilizzando i campi e i metodi della classe bean, che è molto meglio.

Ho trascorso parecchio tempo a pensarci su per il caso Java e credo che le vere ragioni siano:

1. Codice per l'interfaccia, non per l'implementazione
2. Le interfacce specificano solo metodi, non campi

In altre parole, l'unico modo per specificare un campo in un'interfaccia è fornire un metodo per scrivere un nuovo valore e un metodo per leggere il valore corrente.

Quei metodi sono il famigerato getter e setter ....

Può essere utile per il caricamento lento. Supponi che l'oggetto in questione sia archiviato in un database e non vuoi andare a prenderlo se non ne hai bisogno. Se l'oggetto viene recuperato da un getter, l'oggetto interno può essere nullo fino a quando qualcuno non lo richiede, quindi puoi andare a prenderlo alla prima chiamata al getter.

Ho avuto una classe di pagine di base in un progetto che mi è stato consegnato che stava caricando alcuni dati da un paio di chiamate al servizio Web diverse, ma i dati in quelle chiamate al servizio Web non erano sempre utilizzati in tutte le pagine figlio. I servizi Web, per tutti i vantaggi, introducono nuove definizioni di "lento", quindi non si desidera effettuare una chiamata al servizio Web se non è necessario.

Sono passato dai campi pubblici ai getter e ora i getter controllano la cache e, se non è presente, chiama il servizio web. Quindi, con un po 'di wrapping, sono state impedite molte chiamate al servizio web.

Quindi il getter mi salva dal tentativo di capire, su ogni pagina figlio, di cosa avrò bisogno. Se ne ho bisogno, chiamo il getter, e lo troverò per me se non lo ho già.

    protected YourType _yourName = null;
    public YourType YourName{
      get
      {
        if (_yourName == null)
        {
          _yourName = new YourType();
          return _yourName;
        }
      }
    }

Un aspetto che mi è sfuggito finora nelle risposte, la specifica di accesso:

• per i membri hai una sola specifica di accesso sia per l'impostazione che per la ricezione
• per setter e getter puoi perfezionarlo e definirlo separatamente

EDIT: ho risposto a questa domanda perché ci sono un sacco di persone che imparano a programmare chiedendo questo, e la maggior parte delle risposte sono molto tecnicamente competenti, ma non sono così facili da capire se sei un principiante. Eravamo tutti principianti, quindi ho pensato di provare la mia risposta a una risposta più amichevole per i principianti.

I due principali sono il polimorfismo e la validazione. Anche se è solo una stupida struttura di dati.

Diciamo che abbiamo questa semplice classe:

public class Bottle {
  public int amountOfWaterMl;
  public int capacityMl;
}

Una classe molto semplice che contiene la quantità di liquido contenuta e la sua capacità (in millilitri).

Cosa succede quando lo faccio:

Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;

Bene, non ti aspetteresti che funzioni, giusto? Volete che ci sia una specie di controllo di sanità mentale. E peggio ancora, se non avessi mai specificato la capacità massima? Oh caro, abbiamo un problema.

Ma c'è anche un altro problema. E se le bottiglie fossero solo un tipo di contenitore? E se avessimo diversi contenitori, tutti con capacità e quantità di liquido riempito? Se potessimo solo creare un'interfaccia, potremmo permettere al resto del nostro programma di accettare quell'interfaccia, e bottiglie, taniche e ogni altra cosa funzionerebbero semplicemente in modo intercambiabile. Non sarebbe meglio? Poiché le interfacce richiedono metodi, anche questa è una buona cosa.

Finiremmo con qualcosa del tipo:

public interface LiquidContainer {
  public int getAmountMl();
  public void setAmountMl(int amountMl);
  public int getCapacityMl();
}

Grande! E ora cambiamo solo Bottle in questo:

public class Bottle extends LiquidContainer {
  private int capacityMl;
  private int amountFilledMl;

  public Bottle(int capacityMl, int amountFilledMl) {
    this.capacityMl = capacityMl;
    this.amountFilledMl = amountFilledMl;
    checkNotOverFlow();
  }

  public int getAmountMl() {
    return amountFilledMl;
  }

  public void setAmountMl(int amountMl) {
     this.amountFilled = amountMl;
     checkNotOverFlow();
  }
  public int getCapacityMl() {
    return capacityMl;
  }

  private void checkNotOverFlow() {
    if(amountOfWaterMl > capacityMl) {
      throw new BottleOverflowException();
    }
}

Lascerò la definizione di BottleOverflowException come esercizio per il lettore.

Ora nota quanto è più robusto. Ora possiamo gestire qualsiasi tipo di contenitore nel nostro codice accettando LiquidContainer anziché Bottle. E come queste bottiglie gestiscono questo tipo di cose possono differire. Puoi avere bottiglie che scrivono il loro stato su disco quando cambia, o bottiglie che salvano su database SQL o GNU sa cos'altro.

E tutti questi possono avere modi diversi di gestire varie whoopsie. Il Bottle controlla solo e se trabocca genera una RuntimeException. Ma potrebbe essere la cosa sbagliata da fare. (C'è una discussione utile da fare sulla gestione degli errori, ma lo sto tenendo molto semplice qui apposta. Le persone nei commenti indicheranno probabilmente i difetti di questo approccio semplicistico.;)

E sì, sembra che passiamo da un'idea molto semplice a ottenere rapidamente risposte molto migliori.

Si noti inoltre che non è possibile modificare la capacità di una bottiglia. Ora è incastonato nella pietra. Potresti farlo con un int dichiarandolo finale. Ma se questo fosse un elenco, potresti svuotarlo, aggiungere nuove cose e così via. Non puoi limitare l'accesso a toccare le viscere.

C'è anche la terza cosa che non tutti hanno affrontato: getter e setter usano le chiamate di metodo. Ciò significa che sembrano metodi normali ovunque. Invece di avere strana sintassi specifica per DTO e roba del genere, hai la stessa cosa ovunque.

Nei linguaggi che non supportano le "proprietà" (C ++, Java) o che richiedono la ricompilazione dei client quando si cambiano i campi in proprietà (C #), è più semplice modificare i metodi get / set. Ad esempio, l'aggiunta della logica di convalida a un metodo setFoo non richiederà la modifica dell'interfaccia pubblica di una classe.

In linguaggi che supportano proprietà "reali" (Python, Ruby, forse Smalltalk?) Non ha senso ottenere / impostare metodi.

Uno dei principi di base del design OO: incapsulamento!

Ti offre molti vantaggi, uno dei quali è che puoi cambiare l'implementazione del getter / setter dietro le quinte, ma qualsiasi consumatore di quel valore continuerà a funzionare finché il tipo di dati rimane lo stesso.

È necessario utilizzare getter e setter quando:

• Hai a che fare con qualcosa che è concettualmente un attributo, ma:
  • La tua lingua non ha proprietà (o qualche meccanismo simile, come le tracce variabili di Tcl), o
  • Il supporto della proprietà della tua lingua non è sufficiente per questo caso d'uso o
  • Le convenzioni idiomatiche della tua lingua (o talvolta del tuo framework) incoraggiano getter o setter per questo caso d'uso.

Quindi questa è molto raramente una domanda generale di OO; è una domanda specifica della lingua, con risposte diverse per lingue diverse (e diversi casi d'uso).

Da un punto di vista della teoria OO, getter e setter sono inutili. L'interfaccia della tua classe è ciò che fa, non quale sia il suo stato. (In caso contrario, hai scritto la classe sbagliata.) In casi molto semplici, dove ciò che una classe fa è, ad esempio, rappresentare un punto in coordinate rettangolari, * gli attributi fanno parte dell'interfaccia; Getter e setter lo appannano. Ma in casi tutt'altro che molto semplici, né gli attributi né i getter e i setter fanno parte dell'interfaccia.

Detto in altro modo: se ritieni che i consumatori della tua classe non dovrebbero nemmeno sapere di avere un spamattributo, tanto meno essere in grado di cambiarlo volenti o nolenti, quindi dare loro unset_spam metodo è l'ultima cosa che vuoi fare.

_{* Anche per quella semplice classe, potresti non voler necessariamente consentire l'impostazione dei valori xe y. Se questo è davvero una classe, non dovrebbe avere metodi come translate, rotatee così via? Se è solo una classe perché la tua lingua non ha record / strutture / tuple nominate, allora questa non è davvero una questione di OO ...}

Ma nessuno sta mai progettando OO in generale. Stanno progettando e realizzando, in un linguaggio specifico. E in alcune lingue, getter e setter sono tutt'altro che inutili.

Se la tua lingua non ha proprietà, l'unico modo per rappresentare qualcosa che è concettualmente un attributo, ma in realtà è calcolato, o validato, ecc., È attraverso getter e setter.

Anche se la tua lingua ha proprietà, ci possono essere casi in cui sono insufficienti o inappropriati. Ad esempio, se si desidera consentire alle sottoclassi di controllare la semantica di un attributo, nelle lingue senza accesso dinamico, una sottoclasse non può sostituire una proprietà calcolata con un attributo.

Per quanto riguarda "e se volessi cambiare la mia implementazione in un secondo momento?" domanda (che viene ripetuta più volte in termini diversi sia nella domanda del PO che nella risposta accettata): se si tratta in realtà di una modifica di implementazione pura e si è iniziato con un attributo, è possibile cambiarlo in una proprietà senza influire sull'interfaccia. A meno che, ovviamente, la tua lingua non lo supporti. Quindi questo è davvero di nuovo lo stesso caso.

Inoltre, è importante seguire i modi di dire della lingua (o del framework) che stai utilizzando. Se scrivi bellissimo codice in stile Ruby in C #, qualsiasi sviluppatore C # esperto diverso da te avrà problemi a leggerlo, e questo è male. Alcune lingue hanno culture più forti attorno alle loro convenzioni rispetto ad altre. E potrebbe non essere una coincidenza che Java e Python, che si trovano alle estremità opposte dello spettro per quanto sono getter idiomatici, abbiano due delle culture più forti.

Oltre ai lettori umani, ci saranno biblioteche e strumenti che si aspettano che tu segua le convenzioni e che ti rendano la vita più dura se non lo fai. Collegare i widget di Interface Builder a tutto tranne che alle proprietà ObjC, o usare certe librerie di derisione Java senza getter, ti sta solo rendendo la vita più difficile. Se gli strumenti sono importanti per te, non combatterli.

Dal punto di vista del design dell'orientamento agli oggetti entrambe le alternative possono essere dannose per il mantenimento del codice indebolendo l'incapsulamento delle classi. Per una discussione puoi consultare questo eccellente articolo: http://typicalprogrammer.com/?p=23

I metodi getter e setter sono metodi di accesso, nel senso che sono generalmente un'interfaccia pubblica per cambiare i membri della classe privata. Utilizzare i metodi getter e setter per definire una proprietà. Accedete ai metodi getter e setter come proprietà esterne alla classe, anche se le definite all'interno della classe come metodi. Le proprietà esterne alla classe possono avere un nome diverso dal nome della proprietà nella classe.

Ci sono alcuni vantaggi nell'uso dei metodi getter e setter, come la possibilità di creare membri con funzionalità sofisticate a cui è possibile accedere come proprietà. Ti consentono inoltre di creare proprietà di sola lettura e di sola scrittura.

Anche se i metodi getter e setter sono utili, dovresti fare attenzione a non usarli eccessivamente perché, tra le altre cose, possono rendere più difficile la manutenzione del codice in determinate situazioni. Inoltre, forniscono l'accesso all'implementazione della tua classe, come i membri pubblici. La pratica OOP scoraggia l'accesso diretto alle proprietà all'interno di una classe.

Quando si scrivono le classi, si è sempre incoraggiati a rendere private quante più variabili possibili delle proprie istanze e aggiungere i metodi getter e setter di conseguenza. Questo perché ci sono diverse volte in cui potresti non voler permettere agli utenti di cambiare determinate variabili all'interno delle tue classi. Ad esempio, se si dispone di un metodo statico privato che tiene traccia del numero di istanze create per una classe specifica, non si desidera che un utente modifichi tale contatore utilizzando il codice. Solo l'istruzione del costruttore dovrebbe incrementare quella variabile ogni volta che viene chiamata. In questa situazione, è possibile creare una variabile di istanza privata e consentire un metodo getter solo per la variabile contatore, il che significa che gli utenti sono in grado di recuperare il valore corrente solo utilizzando il metodo getter e non saranno in grado di impostare nuovi valori usando il metodo setter.

Il codice si evolve . privateè ottimo per quando è necessaria la protezione dei membri dei dati . Alla fine tutte le classi dovrebbero essere una sorta di "miniprogrammi" che hanno un'interfaccia ben definita che non si può semplicemente rovinare con gli interni di .

Detto questo, lo sviluppo del software non consiste nell'impostare quella versione finale della classe come se al primo tentativo stessi premendo una statua di ghisa. Mentre ci lavori, il codice è più simile all'argilla. Si evolve man mano che lo sviluppi e scopri di più sul dominio del problema che stai risolvendo. Durante le lezioni di sviluppo possono interagire tra loro quanto dovrebbero (dipendenza che prevedi di scomporre), unire o dividere. Quindi penso che il dibattito si riduca a persone che non vogliono scrivere religiosamente

int getVar() const { return var ; }

Quindi hai:

doSomething( obj->getVar() ) ;

Invece di

doSomething( obj->var ) ;

Non solo è getVar()visivamente rumoroso, ma dà questa illusione che gettingVar()è in qualche modo un processo più complesso di quanto non sia in realtà. Il modo in cui tu (come scrittore di classe) consideri la santità varparticolarmente confuso per un utente della tua classe se ha un setter passthru - allora sembra che tu stia aprendo queste porte per "proteggere" qualcosa che insisti sia prezioso, (la santità di var), ma anche tu concedi varla protezione non vale molto per la capacità di chiunque di entrare eset var per qualunque valore vogliano, senza che tu nemmeno sbirciate da quello che stanno facendo.

Quindi programma come segue (assumendo un approccio di tipo "agile" - cioè quando scrivo codice non sapendo esattamente cosa farà / non ho tempo o esperienza per pianificare un elaborato set di interfacce in stile cascata):

1) Inizia con tutti i membri pubblici per gli oggetti di base con dati e comportamento. Questo è il motivo per cui in tutto il mio codice "esempio" in C ++ mi noterai che uso structinvece che classovunque.

2) Quando il comportamento interno di un oggetto per un membro di dati diventa abbastanza complesso (ad esempio, gli piace mantenere un interno std::listin un qualche tipo di ordine), vengono scritte le funzioni del tipo di accessorio. Perché sto programmando da solo, non sempre impostare il membro privatesubito, ma da qualche parte lungo l'evoluzione della classe del membro sarà "promosso" a uno protectedoprivate .

3) Le classi che sono completamente specificati ulteriormente e avere regole rigide sulla loro struttura interna (cioè che sanno esattamente quello che stanno facendo, e non si è a "fuck" (termine tecnico) con i suoi interni) viene data la classdesignazione, di default soci privati, e solo pochi membri selezionati possono essere public.

Trovo che questo approccio mi permetta di evitare di sedermi lì e scrivere religiosamente getter / setter quando molti membri dei dati vengono migrati, spostati, ecc. Durante le prime fasi dell'evoluzione di una classe.

Vi è una buona ragione per considerare l'utilizzo di accessor se non esiste eredità di proprietà. Vedi il prossimo esempio:

public class TestPropertyOverride {
    public static class A {
        public int i = 0;

        public void add() {
            i++;
        }

        public int getI() {
            return i;
        }
    }

    public static class B extends A {
        public int i = 2;

        @Override
        public void add() {
            i = i + 2;
        }

        @Override
        public int getI() {
            return i;
        }
    }

    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.i);
        a.add();
        System.out.println(a.i);
        System.out.println(a.getI());
    }
}

Produzione:

0
0
4

Getter e setter vengono utilizzati per implementare due degli aspetti fondamentali della programmazione orientata agli oggetti che sono:

1. Astrazione
2. incapsulamento

Supponiamo di avere una classe Employee:

package com.highmark.productConfig.types;

public class Employee {

    private String firstName;
    private String middleName;
    private String lastName;

    public String getFirstName() {
      return firstName;
    }
    public void setFirstName(String firstName) {
       this.firstName = firstName;
    }
    public String getMiddleName() {
        return middleName;
    }
    public void setMiddleName(String middleName) {
         this.middleName = middleName;
    }
    public String getLastName() {
        return lastName;
    }
    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getFullName(){
        return this.getFirstName() + this.getMiddleName() +  this.getLastName();
    }
 }

Qui i dettagli di implementazione di Nome completo sono nascosti all'utente e non sono accessibili direttamente all'utente, a differenza di un attributo pubblico.

Un altro uso (in linguaggi che supportano le proprietà) è che setter e getter possono implicare che un'operazione non è banale. In genere, si desidera evitare di fare qualsiasi cosa computazionalmente costosa in una proprietà.

Un vantaggio relativamente moderno di getter / setter è che è più facile sfogliare il codice negli editor di codici con tag (indicizzati). Ad esempio, se si desidera vedere chi imposta un membro, è possibile aprire la gerarchia di chiamata del setter.

D'altra parte, se il membro è pubblico, gli strumenti non consentono di filtrare l'accesso in lettura / scrittura al membro. Quindi devi arrancare attraverso tutti gli usi del membro.

In un linguaggio orientato agli oggetti i metodi e i loro modificatori di accesso dichiarano l'interfaccia per quell'oggetto. Tra i metodi di costruzione e accessor e mutatore è possibile per lo sviluppatore controllare l'accesso allo stato interno di un oggetto. Se le variabili sono semplicemente dichiarate pubbliche, non c'è modo di regolare tale accesso. E quando stiamo usando setter possiamo limitare l'utente per l'input di cui abbiamo bisogno. Significa che il feed per quella variabile passerà attraverso un canale appropriato e il canale è predefinito da noi. Quindi è più sicuro usare setter.

Inoltre, questo è "a prova di futuro" la tua classe. In particolare, passare da un campo a una proprietà è un'interruzione ABI, quindi se successivamente decidi che hai bisogno di più logica di un semplice "set / get the field", allora devi interrompere ABI, che ovviamente crea problemi per qualsiasi cosa altro già compilato contro la tua classe.

Vorrei solo lanciare l'idea dell'annotazione: @getter e @setter. Con @getter, dovresti essere in grado di obj = class.field ma non class.field = obj. Con @setter, viceversa. Con @getter e @setter dovresti essere in grado di fare entrambe le cose. Ciò preserverebbe l'incapsulamento e ridurrebbe i tempi non chiamando metodi banali in fase di esecuzione.