Quando o perché si dovrebbero usare getter / setter per le proprietà di classe invece di renderle semplicemente proprietà pubbliche?

Penso che tu debba cercare di usare sempre getter e setter. Nel tuo caso hai qualcosa del tipo:

obj = new Obj();
obj.prop = "1";

Che cosa succede se hai altri 1000 riferimenti a obj.prop ? E poi, decidi che obj.prop non può essere negativo come "-4" (solo un esempio). In questo caso, come controlleresti che nessuno trasmetta tali valori all'oggetto? Se hai usato un metodo setProp sarà facile:

setProp(val) {
    if(val < 0)
      // doSomething
    prop = val;
}

In generale, questo è il tipo di situazioni in cui l'uso di setter e getter renderebbe più semplice la manutenzione del codice. Ci sono molte altre situazioni simili e la maggior parte di esse incoraggia l'uso di setter e getter.

Tuttavia, a volte uso classi con campi pubblici. Lo faccio quando quella classe è una classe privata interiore; il che significa che non è usato al di fuori della classe genitore. In questi casi la scusa è: "So sempre quali dati assegnare e che è valido". Tuttavia, è sempre un caso di pigrizia.

Alcuni dicono che è più veloce in runtime assegnare i valori direttamente, e questo potrebbe essere vero ma penso che sia difficile notare una differenza significativa in un modo o nell'altro.

Nelle lingue senza le strutture in stile C, è generalmente accettato, anche incoraggiato, l'uso di campi pubblici per "Plain Old Data" classi, come numeri complessi, punti, ecc. Altrimenti, getter e setter sono raccomandati.

Oltre all'ottimo punto di Cristian sulla manutenibilità, rende anche il debug molto più facile avere un solo posto in cui un valore può essere cambiato. Ad esempio, forse un campo viene utilizzato per indicizzare un array e si ottiene un'eccezione fuori dai limiti. Senza un setter, passerai attraverso l'intero codice trovando l'unico punto che lo imposta al valore sbagliato. Con un setter, hai appena messo un punto di interruzione nel setter e lo sai molto rapidamente. I setter ti consentono anche di applicare la convalida dei dati.

In altre parole, è leggermente più digitante a breve termine che forse non è più necessario in seguito, ma è estremamente utile quando lo è.

Non c'è alcun motivo particolare per usare getter / setter se non ne hai bisogno. Proprietà pubbliche ci sono, dopo tutto, per una ragione. Altrimenti si sta solo ingombrando il codice con le funzioni getter e setter che potrebbero non fare mai nulla di più che assegnare un valore.

Alcuni di essi dipendono dalla lingua - alcune lingue ti guidano di più rispetto ad altri. Delphi, ad esempio, ha proprietà, che possono effettivamente agire come o un wrapper attorno a una variabile privata, o un getter / setter. Quindi non c'è bisogno di usare un metodo getter / setter se non ne hai bisogno immediatamente, dal momento che una variabile pubblica può essere rifusa come una proprietà usando getter / setter, mantenendo l'interfaccia di quella classe lo stesso per il codice che la usa (es. , anche se può essere un getter / setter sotto il cofano, per codificare l'impostazione di una proprietà di un oggetto, lo fa ancora come se fosse una variabile pubblica).

Fondamentalmente il mio consiglio è quello che è sempre ... preoccuparsi meno di come gli altri dicono che dovresti fare il codice e di più per assicurarti che i tuoi progetti siano fatti e che siano facilmente mantenibili. Se ciò significa getter / setter per te, allora usa 'em. Se non funziona, va bene anche.

Oltre ai buoni punti già menzionati, per C # .NET:

A - A differenza dei campi, una proprietà non ha spazio di archiviazione associato all'interno dell'oggetto.

B - Il valore della proprietà viene impostato (o calcolato) quando si accede non quando l'oggetto viene istanziato.

Nota: Un valore di campo può essere impostato solo quando viene utilizzato se si utilizza la parola chiave volatile quando si definisce il campo.

C - Una proprietà può assegnare un valore calcolato in base a dati di istanza specifici al risultato (o input) mentre nel caso di un campo, è necessario richiamare un metodo per farlo, questo rende il codice confuso perché sarebbe richiedono entrambi i metodi e le proprietà per ottenere lo stato dell'oggetto.

D - I campi non possono essere writeonly ma Properties può ( writeonly è usato raramente ma è ancora parte della lingua).

Riferimento: Source per A e B sopra è il libro: Accelerated C # 2010. Le informazioni sono state riformulate in base alla mia comprensione. Per ulteriori informazioni sulla parola chiave volatile, vedere Black-Wasp-Volatile parole chiave .