variabili pubbliche vs variabili private con accessori

Question

Qualcun altro ha visto persone fare questo:

private string _name;
public string Name{ get{ return _name; } set{ _name = value;}}

Comprendo l'uso degli accessori se hai intenzione di esercitare una sorta di controllo su come viene impostato o eseguire una sorta di funzione su di esso quando c'è un get. Ma se hai intenzione di farlo, perché non rendere pubblica la variabile per cominciare? Mi sto perdendo qualcosa?

Answer 1

Se rendi il membro un campo pubblico, non puoi successivamente trasformarlo in una proprietà senza cambiare l'interfaccia nella tua classe. Se lo esponi come una proprietà fin dall'inizio, puoi apportare qualsiasi modifica alle funzioni di accesso alla proprietà di cui hai bisogno e l'interfaccia della classe rimane invariata.

Si noti che a partire da C # 3.0, è possibile implementare una proprietà senza creare un campo di supporto, ad esempio:

public string Name { get; set; }

Ciò rimuove praticamente l'unica giustificazione per non implementare i campi pubblici come proprietà.

Answer 2

Se si definisce un'interfaccia pubblica con una proprietà nell'assembly A, è possibile utilizzare questa interfaccia nell'assembly B.

Ora puoi cambiare l'implementazione della proprietà (magari recuperare il valore da un database invece di memorizzarlo in un campo). Quindi è possibile ricompilare l'assieme A e sostituirne uno precedente. L'Assemblea B andrebbe bene perché l'interfaccia non sarebbe cambiata.

Tuttavia, se inizialmente avessi iniziato con un campo pubblico e avessi deciso che non era adatto e volevi cambiare l'implementazione e per fare ciò che dovevi convertire in una proprietà, ciò significherebbe che avresti cambiare l'interfaccia pubblica dell'assembly A. Qualsiasi client di tale interfaccia (incluso l'assembly B) dovrebbe anche essere ricompilato e sostituito per poter lavorare con questa nuova interfaccia.

Quindi, è meglio iniziare con una proprietà inizialmente. Questo incapsula l'implementazione della proprietà, lasciandoti libero di cambiarla in futuro senza doversi preoccupare di quali clienti (incluso l'assemblaggio B) siano già in circolazione nel mondo usando l'assemblaggio A. Perché, se ci sono già clienti nel mondo facendo uso dell'assembly A, cambiando l'interfaccia si distruggerebbero tutti i client. Se vengono utilizzati da un altro team della tua azienda o da un'altra società, non saranno felici se rompi le loro assemblee cambiando l'interfaccia della tua!

Answer 3

L'idea è che se si utilizzano gli accessori, l'implementazione sottostante può essere modificata senza modificare l'API. Ad esempio, se si decide che quando si imposta il nome, è necessario aggiornare anche una casella di testo o un'altra variabile, senza modificare il codice client.

Answer 4

Potrebbe valere la pena notare che DataBinding in .NET rifiuta anche di lavorare su campi pubblici e richiede proprietà. Quindi potrebbe essere un altro motivo.

Answer 5

Buone pratiche di programmazione. Questo è un modello molto comune che si adatta alle metodologie di progettazione OO. Esponendo un campo pubblico si espongono gli interni di come questi dati vengono archiviati. L'uso di una proprietà pubblica consente invece una maggiore flessibilità per modificare il modo in cui i dati vengono archiviati internamente e non interrompere l'interfaccia pubblica. Consente inoltre un maggiore controllo su ciò che accade quando si accede ai dati (inizializzazione lenta, controlli null, ecc.)

Answer 6

Le variabili fanno parte dell'implementazione di una classe. Le proprietà rappresentano in modo più logico l'interfaccia. Con C # 3.0, le proprietà implementate automaticamente lo rendono un gioco da ragazzi dall'inizio.

Ho scritto più pensieri su questo, inclusi i vari modi in cui il passaggio da una variabile a una proprietà interrompe non solo la compatibilità binaria ma anche la compatibilità dei sorgenti, in un articolo sull'argomento .

Answer 7

Preparazione. Non si sa mai quando si desidera rimuovere l'accessor set lungo la strada, eseguire operazioni aggiuntive nel setter o modificare l'origine dati per get.

Answer 8

I membri accessibili pubblicamente dovrebbero in genere essere metodi e non campi. È solo una buona pratica e quella pratica ti aiuta a garantire che lo stato incapsulato dei tuoi oggetti sia sempre sotto il tuo controllo.

Answer 9

Per l'incapsulamento, non è consigliabile utilizzare i campi pubblici.

http://my.safaribooksonline.com/9780321578815/ch05lev1sec5?displaygrbooks=0

Come ha detto Chris Anderson più avanti in questo libro, sarebbe l'ideale se il chiamante fosse cieco alla differenza tra campo e proprietà.

Answer 10

Per mantenere un alto grado di estensibilità senza il fastidio di ricompilare tutti i tuoi assembly, vuoi usare proprietà pubbliche come accessori. Seguendo un "contratto" o un meccanismo definito che descriva come i tuoi oggetti scambieranno dati verrà messo in atto un insieme di regole. Questo contratto viene applicato con un'interfaccia e adempiuto dai vincitori e setter della tua classe che eredita questa interfaccia.

In seguito, se si creano classi aggiuntive da tale interfaccia, si ha la flessibilità di aderire al contratto con l'uso delle proprietà, ma poiché si stanno fornendo i dati tramite getter e setter, l'implementazione o il processo di assemblaggio dei dati puoi tutto quello che vuoi, purché restituisca il tipo che il "contratto" si aspetta.