Campi pubblici e proprietà automatiche

Ci viene spesso detto che dovremmo proteggere l'incapsulamento creando metodi getter e setter (proprietà in C #) per i campi di classe, invece di esporre i campi al mondo esterno.

Ma ci sono molte volte in cui un campo è lì per contenere un valore e non richiede alcun calcolo per ottenere o impostare. Per questi faremmo tutti questo numero:

public class Book
{
    private string _title;

    public string Title
    {
          get{ return _title;  }
          set{ _title = value; }
    }
}

Bene, ho una confessione, non potevo sopportare di scrivere tutto questo (davvero, non doveva scriverlo, doveva guardarlo), quindi sono diventato un ladro e ho usato campi pubblici.

Poi arriva C # 3.0 e vedo che hanno aggiunto proprietà automatiche:

public class Book
{
    public string Title {get; set;} 
}

che è più ordinato, e ne sono grato, ma davvero, cosa c'è di così diverso che fare un campo pubblico?

public class Book
{
    public string Title;
}

In una domanda correlata che avevo qualche tempo fa, c'era un link a un post sul blog di Jeff, che spiegava alcune differenze.

Proprietà vs. variabili pubbliche

• Reflection funziona in modo diverso su variabili e proprietà, quindi se si fa affidamento su reflection, è più semplice utilizzare tutte le proprietà.
• Non è possibile eseguire il databind rispetto a una variabile.

• La modifica di una variabile in una proprietà è una rottura. Per esempio:

  TryGetTitle(out book.Title); // requires a variable

Ignorando i problemi dell'API, la cosa che trovo più preziosa nell'uso di una proprietà è il debug.

Il debugger CLR non supporta i punti di interruzione dei dati (la maggior parte dei debugger nativi lo fanno). Quindi non è possibile impostare un punto di interruzione sulla lettura o scrittura di un determinato campo su una classe. Ciò è molto limitante in alcuni scenari di debug.

Poiché le proprietà sono implementate come metodi molto sottili, è possibile impostare punti di interruzione sulla lettura e scrittura dei loro valori. Questo dà loro un vantaggio sui campi.

Il passaggio da un campo a una proprietà comporta la rottura del contratto (ad es. Richiede la ricompilazione di tutto il codice di riferimento). Quindi, quando hai un punto di interazione con altre classi - qualsiasi membro pubblico (e generalmente protetto), vuoi pianificare una crescita futura. Fallo utilizzando sempre le proprietà.

Oggi non è nulla per renderlo un'auto-proprietà e 3 mesi dopo capisci che vuoi renderlo carico di energia e metti un segno di spunta nel getter. Se hai usato un campo, questo è un cambiamento di ricompilazione nel migliore dei casi e impossibile nel peggiore dei casi, a seconda di chi e cos'altro dipende dai tuoi assiemi.

Solo perché nessuno lo ha menzionato: non è possibile definire i campi sulle interfacce. Quindi, se devi implementare un'interfaccia specifica che definisce le proprietà, le proprietà automatiche a volte sono davvero una bella funzionalità.

Un'enorme differenza che viene spesso trascurata e non è menzionata in nessun'altra risposta: ignorare . Puoi dichiarare le proprietà virtuali e sovrascriverle mentre non puoi fare lo stesso per i campi dei membri pubblici.

Riguarda il controllo delle versioni e la stabilità dell'API. Non c'è alcuna differenza, nella versione 1 - ma in seguito, se decidi di renderlo una proprietà con un qualche tipo di controllo degli errori nella versione 2, non devi cambiare la tua API - nessuna modifica del codice, ovunque, tranne che la definizione della proprietà.

Un altro vantaggio delle proprietà implementate automaticamente sui campi pubblici è che puoi rendere gli accessi impostati privati ​​o protetti, fornendo alla classe di oggetti in cui è stato definito un controllo migliore rispetto a quello dei campi pubblici.

Non c'è niente di sbagliato nel creare un campo public. Ma ricorda che creare getter/settercon i privatecampi non è incapsulamento. IMO, se non ti interessano altre funzionalità di a Property, potresti anche farcela public.

Se in seguito decidi di verificare che il titolo sia univoco, confrontandolo con una raccolta o un database, puoi farlo nella proprietà senza modificare alcun codice che dipende da esso.

Se utilizzi solo un attributo pubblico, avrai meno flessibilità.

La maggiore flessibilità senza rompere il contratto è la cosa più importante per me nell'uso delle proprietà e, fino a quando non ho effettivamente bisogno della flessibilità, l'auto-generazione ha più senso.

Una cosa che trovo molto utile oltre a tutto il codice e i motivi del test è che se si tratta di una proprietà contro un campo è che l'IDE di Visual Studio mostra i riferimenti per una proprietà ma non un campo.

Il mio pov dopo ha fatto alcune ricerche

1. Convalida.
2. Consenti l'override dell'accessor per modificare il comportamento di una proprietà.
3. Scopo del debug. Saremo in grado di sapere quando e cosa cambia la proprietà impostando un breakpoint nell'accessor.
4. Possiamo avere solo un set di campi. Ad esempio, public set () e private get (). Questo non è possibile con il campo pubblico.

Ci dà davvero più possibilità ed estensibilità.