Quali sono i vantaggi della definizione di un attributo privato anziché di un attributo pubblico? Perché dovrei avere il lavoro extra di creare metodi per accedere e modificare gli attributi privati se posso renderli pubblici?Dichiarazione attributo di classe: privato vs pubblico
Se si utilizzano getter/setter è possibile eseguire la logica in caso di modifiche o accesso. È possibile convalidare l'input, invece di assumere che sia sempre corretto. È possibile tenere traccia di quante volte viene recuperato il valore.
Soprattutto, è un buon design. Ti dà, lo sviluppatore della classe, più controllo su come viene utilizzato e una maggiore capacità di prevenire l'abuso, l'abuso o semplicemente qualcuno che fa qualcosa di sbagliato.
Se si crea il metodo di accesso, si separa l'implementazione dall'interfaccia.
Perché si dovrebbe sempre sforzarsi di difendere l'implementazione dall'interfaccia. Se rendi pubblico un attributo, stai facendo sapere al cliente qual è la tua implementazione per quell'attributo.
Questo ti vincola a mantenere non solo l'interfaccia, ma anche l'implementazione.
Inoltre, è possibile eseguire altre operazioni intelligenti come la convalida, il controllo degli accessi, la contabilità, se si utilizza un metodo. Se rendi pubblico un attributo, hai molto meno controllo di ciò che il client può fare con quell'attributo
Un attributo privato ti fornisce un livello di protezione dagli utenti della tua classe, per quell'attributo. Se si utilizza un attributo pubblico, sarà necessario aggiungere più logica per verificare i valori non validi in anticipo, che possono essere più utili, nonché più computazionalmente costosi.
Anche gli attributi pubblici "ingombrano" l'interfaccia. Il minor numero di attributi pubblici che presenti, il "più pulito" e più facile sarà il tuo oggetto con cui lavorare. Avere alcuni attributi privati ti dà flessibilità e allo stesso tempo fornisce una facilità d'uso che altrimenti non ci sarebbe.
In C# è idiomatico. Ciò significa che i campi pubblici sarebbero sorprendenti e far sì che altre persone impieghino ancora un po 'di tempo per capire il tuo codice.
Il motivo per cui è idiomatico ha a che fare con le altre spiegazioni fornite dalle persone, ma il fatto che sia idiomatico significa che si dovrebbe preferire una proprietà su un campo pubblico a meno che non ci sia un valido motivo per utilizzare un campo.
A breve termine non ce n'è, tranne che rendere i puristi OOP infelici.
(Suppongo che intenda l'esposizione di proprietà che altrimenti utilizzerebbero getter/setter, ovviamente c'è una grande differenza se si lascia TUTTI i propri attributi pubblici).
A lungo termine ci sono davvero delle buone ragioni per farlo.
In primo luogo, consente di convalidare l'input alla sua origine invece di dover successivamente tracciare l'origine con una combinazione di punti di interruzione dell'hardware e magia nera.
E.g.
void Foo::setWeight(float weight)
{
ASSERTMSG(weight >= 0.0f && weight <= 1.0f, "Weights must fall in [0..1]");
mWeight = weight;
}
Esso permette anche di modificare in seguito il comportamento del vostro oggetto senza bisogno di refactoring codice client.
E.g.
void Foo::setSomething(float thing)
{
mThing = thing;
// 2009/4/2: turns out we need to recalc a few things when this changes..
...
}
Principalmente a causa del concetto OO di incapsulamento. Usando privato si incapsula l'accesso alla variabile dell'oggetto mantenendo il controllo dello stato dell'oggetto. Non consentire agli oggetti esterni di modificare lo stato del tuo oggetto di cui non sei a conoscenza.
Un semplice esempio potrebbe essere un oggetto Pocket.
class Pocket {
public int numberOfCoins = 10;
private boolean haveMoney = true;
public void giveOneCoin(){
if(stillHaveMoney()){
numberOfCoins--;
if(numberOfCoins=<0){
haveMoney=false;
}
}
}
public boolean stillHaveMoney(){
return haveMoney;
}
}
E ora immaginiamo un'altra classe, come di seguito:
class PickPockets {
public void getSomeMoney(Pocket pocket){
pocket.numberOfCoins=0;
}
}
Sicuramente è un semplice esempio. tuttavia questo mostra come sia importante avere il controllo dell'accesso ai campi/attributi della tua classe. Immagina un oggetto più complesso con un controllo dello stato molto più complicato. L'incapsulamento rende migliore l'astrazione e la consistenza dell'oggetto.
Yer, ma quando è stata l'ultima volta che uno dei tuoi corsi è diventato canaglia e ha iniziato a rubare denaro da altri oggetti? – fauxCoder
In futuro, quando il codice è più grande e qualcuno vuole usare il codice, qualcuno potrebbe vedere che l'attributo numberOfCoins è pubblico e cambiarlo direttamente per ottenere il risultato. Ma poi quando chiamano la funzione hasMoney aspettandosi che sia accurata, potrebbero ottenere un risultato errato. – kiwicomb123
In genere si utilizzano dichiarazioni private per i campi che si desidera isolare all'interno della logica del programma, SOLO se lo si ritiene necessario.
Le dichiarazioni pubbliche offrono un maggiore controllo del flusso del proprio programma; puoi cambiare i campi pubblici quando vuoi. Tu sei l'uomo in casa.
Quindi, perché la maggior parte delle persone risponde spontaneamente con un GRANDE SÌ alle dichiarazioni private?
Perché:
La linea di fondo è incredibilmente "commerciale" !! Se lo stai "vendendo", allora vai privato, altrimenti fai ciò che ti piace.
Si sta meglio a lungo termine se tutti gli attributi sono privati. Ciò include non usare i getter. Se si accede ad attributi di oggetti, si interrompe l'incapsulamento e non si esegue affatto OOP. A quel punto, la maggior parte della ragione per la costruzione di una classe è stata sprecata. Perché costruire un castello per proteggere dagli intrusi, quindi lasciare tutte le porte aperte? Oppure (con i getter) accolgono sempre gli intrusi su richiesta.
Le metodologie di "Law of Demeter" e "Tell do not ask" hanno dimostrato di ridurre il tasso di errore nel codice di produzione. L'uso di attributi pubblici non renderà i puristi orientati agli oggetti infelici, li proteggerà semplicemente usando il tuo codice.
Dite ai vostri oggetti cosa fare con i loro attributi, non chiedere loro i valori, manipolarli e riscriverli. Sarebbe come portare un cane a fare una passeggiata e poi sollevare le gambe una ad una per farlo muovere.
A proposito, al contrario, il comportamento dovrebbe essere pubblico. Qualsiasi metodo che sembra dovrebbe essere privato è in realtà un metodo non estratto di un'altra classe. Estrai la classe e il metodo e osserva il tuo design semplificare davanti ai tuoi occhi.
... e perché è desiderabile? – Rob
@Rob Quindi l'implementazione può cambiare completamente e qualsiasi codice che utilizza l'interfaccia non deve mai saperlo. – Kalium