Devo usare le proprietà automatiche?

A prima vista, queste due linee possono sembrare uguali:

public string A;
public string B {get; set;}

ma non sono affatto uguali. Come saprai, se utilizzi un campo pubblico e in futuro devi aggiungere qualche logica per ottenere o impostare il valore, non puoi (a meno che non interrompi l'interfaccia che stai fornendo agli altri). Non puoi, perché il valore non è incapsulato.

Con una proprietà automatica, invece, puoi aggiungere più logica ogni volta che vuoi, senza la necessità di cambiare l'interfaccia fornita dalla classe. Basta sostituire la proprietà automatica con una standard. Oppure, viceversa, è possibile sostituire la proprietà standard con una automatica. Per un utente esterno, nulla cambia.

Quindi no, non stai neanche rompendo da remoto l'incapsulamento. Stai solo usando un pratico zucchero sintattico.

Se puoi, usali. Dietro le quinte il compilatore fa molto di più che rendere pubblico un campo. Il campo è ancora privato.

La proprietà automatica

public string MyField { get; private set; }

verrebbe convertito in qualcosa di simile (la versione lunga)

private string _myfield;

public string MyField
{
  get
  {
    return _myfield;
  }
  private set
  {
    _myfield = value;
  }
}

Internamente il compilatore genererà metodi getter e setter come li conosci da Java. Quindi, non c'è violazione dei principi OOP.

Le proprietà automatiche sono un modo idiomatico di fare getter / setter in C #. Se stai andando a un colloquio e vuoi dimostrare di essere fluente in C #, usa assolutamente le proprietà automatiche. Soprattutto se provieni da uno sfondo Java, dovrebbe essere rassicurante per gli intervistatori se vedono che sei già un passo avanti rispetto alla scrittura di Java in Visual Studio.

Tuttavia, hai ragione nel fatto che l'uso di public string fieldA {get; set;} alla cieca è un odore di codice. È molto allettante e conveniente definire anticipatamente un insieme di proprietà come pubbliche e non tornare mai indietro per verificare se effettivamente dovrebbero far parte dell'interfaccia di classe o meno. E in questo modo puoi effettivamente interrompere l'incapsulamento (come in "nascondere informazioni").

Quindi riassumendo: usali, ma fai attenzione a non trasformarli in campi pubblici glorificati.

So che la tecnologia basata su XAML (WPF, Windows Phone) non accetta campi pubblici come

public string a;

... per l'associazione dei dati in XAML.

Devi invece usare proprietà pubbliche come:

public string a { get; set; }

Anche se sembrano uguali. Quindi sì, fa la differenza.

• Dovresti usare le proprietà per esporre i campi? sì!
• Dovresti usare le proprietà automatiche? quando è possibile / conveniente farlo

Utilizzerei AutoProperties solo per DTO in cui crei solo oggetti da trasferire tra i limiti e senza alcun comportamento.

La mia esperienza con le proprietà automatiche sono:

• Non c'è modo di creare campi di sola lettura! - > Risolto in C # vNext
• Gli sviluppatori non pensano all'incapsulamento.
  • Tendono a rendere molto pubblico
  • Le proprietà ti obbligano a creare uno stato molto mutevole
• Con IList / ICollection hai problemi
  • Non c'è modo di esporre IReadOnlyList / IReadOnlyCollection

Quindi il consiglio è:

• c'tor dovrebbe esprimere le tue dipendenze e i dati in sola lettura.
• non espone mai la lista / raccolta, espone le raccolte di sola lettura
• cambia i dati con i metodi
  • oggetti di valore dovrebbero essere cambiati in modo atomar