Impossibile convincere sull'occultamento dei dati

Gli elementi della pagina devono essere privati. Il problema, in particolare per quanto riguarda la pagina Il modello oggetto , è che gli oggetti pubblici espongono i loro metodi, non i metodi dell'oggetto pagina. Se il metodo dell'oggetto pagina sarebbe solo clickPrintButton() , non c'è molta differenza, ma immagina invece un metodo printOrder() che deve fare clic sul pulsante e attendere che venga visualizzato un messaggio di conferma. E anche nel caso semplice, chiediti quali altri metodi possono essere applicati a un oggetto Button e desideri che il consumatore di CheckoutPaymentConfirmpage li utilizzi.

Se la memoria serve, le ragioni per sviluppare la tecnica di incapsulare i membri con coppie accessorie / mutator sono dovute a problemi storici associati alla manutenzione e al controllo di qualità.

Man mano che un programma cresce, viene mantenuto e vengono aggiunte nuove funzionalità, alcuni dei problemi particolari sono:

1. Un bug emerge dove il valore del membro non è corretto, ma è difficile determinare il motivo per cui è stato impostato così com'era. Il valore può essere utilizzato anche per uno scopo diverso da un chiamante.

2. L'origine dei valori per quel membro cambia. Anziché essere impostato prima del tempo, il valore deve essere recuperato piuttosto che recitato.

L'incapsulamento aiuta a risolvere il problema garantendo che il manutentore della classe abbia una funzione che può essere modificata per assumere il controllo del valore impostato o recuperato e assicurarsi che sia corretto.

Questo è simile alle pratiche di programmazione come minimizzare l'ambito delle variabili e massimizzare la coesione. L'approccio comprende anche la pratica di codifica sicura per convalidare e verificare gli input e gli output. (Una classe rappresenta una chiara preoccupazione / macchina dello stato, ecc.)

Questo dovrebbe essere applicato alla tua situazione particolare? Potete prevedere e controllare con precisione il futuro del software? Considera che se incapsuli e non ne hai mai bisogno, hai perso alcuni minuti di funzioni generate da IDE. Se non lo fai e più tardi ne hai bisogno, può essere economicamente costoso da risolvere, (specialmente in un programma più grande).

Più concisamente, incapsulare l'accesso ai membri della classe in modo coerente come regola è una tecnica tipica per mitigare i rischi economici nella qualità e manutenzione del software.

Fraintende l'occultamento dell'implementazione se pensi che rendere i membri privati, ma fornire getter e setter, è nascondere le informazioni.

Se sto usando la tua classe, e ho un modo di accedere direttamente a un membro tramite un getter, o di sovrascrivere quel membro con un setter, allora non si nasconde l'informazione. La tua classe agisce come un contenitore stupido per i membri che posso manipolare abbastanza direttamente.

Sì, getter e setter possono fare alcune cose belle, come innescare certe azioni. Forse i getter e setter possono essere riscritti per essere chiamate di procedura remota a un server in Russia. Ma quelle cose pulite non nascondono informazioni. Non nascondono come viene implementata la classe, solo alcuni dettagli su come viene implementato quel membro specifico.

In ogni caso, in linguaggi di programmazione decenti, se hai bisogno di questo tipo di astrazione per l'accesso ai membri, puoi iniziare lasciando un membro ordinario accessibile, e successivamente aggiungere metodi getter e setter che si agganciano alla sintassi di accesso ordinaria . Vale a dire, un incarico come obj.memb = foo attiva effettivamente un setter, e la valutazione di obj.memb innesca un getter. Getter-setter contro la sintassi diretta della valutazione e dell'assegnazione è quindi solo un problema di sintassi, mentre l'occultamento dell'implementazione ha a che fare con la semantica, e ruota attorno a fornire l'accesso no ai membri. Un oggetto che nasconde la sua implementazione può essere manipolato solo con metodi su quell'oggetto, nessuno dei quali fornisce accesso diretto a nessun membro.