Auto-proprietà C # 3.0: utile o no? [chiuso]

Nota: questo è stato pubblicato quando stavo iniziando C #. Con la conoscenza del 2014, posso davvero dire che le proprietà automatiche sono tra le cose migliori che siano mai successe al linguaggio C #.

Sono abituato a creare le mie proprietà in C # usando un campo privato e uno pubblico:

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Ora, con .NET 3.0, abbiamo ottenuto le proprietà automatiche:

public string Title { get; set; }

So che questa è una domanda più filosofica / soggettiva, ma c'è qualche motivo per usare queste proprietà automatiche se non dal salvare cinque righe di codice per ciascun campo? La mia lamentela personale è che quelle proprietà mi nascondono cose e non sono un grande fan della magia nera.

In effetti, il campo privato nascosto non viene nemmeno visualizzato nel debugger, il che è OK dato che le funzioni get / set non fanno nulla. Ma quando voglio implementare effettivamente qualche logica getter / setter, devo usare comunque la coppia privata / pubblica.

Vedo il vantaggio di salvare un sacco di codice (uno contro sei righe) senza perdere la possibilità di cambiare la logica getter / setter in un secondo momento, ma poi posso già farlo semplicemente dichiarando un campo pubblico "Titolo stringa pubblica" senza la necessità di {get; impostato; }, risparmiando così anche più codice.

Quindi, cosa mi sto perdendo qui? Perché qualcuno dovrebbe effettivamente voler usare le proprietà automatiche?

Li usiamo sempre in Stack Overflow.

Potresti anche essere interessato a una discussione su Proprietà vs. Variabili pubbliche . Questo è davvero ciò a cui questa è una reazione e, a tal fine, è grandioso.

Sì, salva solo il codice. È molto più facile da leggere quando ne hai un sacco. Sono più veloci da scrivere e più facili da mantenere. Il salvataggio del codice è sempre un buon obiettivo.

È possibile impostare diversi ambiti:

public string PropertyName { get; private set; }

In modo che la proprietà possa essere modificata solo all'interno della classe. Questo non è davvero immutabile in quanto è ancora possibile accedere al setter privato attraverso la riflessione.

A partire da C # 6 puoi anche creare readonlyproprietà reali , ovvero proprietà immutabili che non possono essere modificate al di fuori del costruttore:

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

Al momento della compilazione diventerà:

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

In classi immutabili con molti membri questo risparmia molto codice in eccesso.

I tre grandi svantaggi dell'utilizzo dei campi anziché delle proprietà sono:

1. Non è possibile eseguire il databind su un campo mentre è possibile su una proprietà
2. Se inizi utilizzando un campo, non puoi successivamente (facilmente) cambiarlo in una proprietà
3. Esistono alcuni attributi che è possibile aggiungere a una proprietà che non è possibile aggiungere a un campo

Personalmente adoro le proprietà automatiche. Cosa c'è di sbagliato nel salvare le righe di codice? Se vuoi fare cose in getter o setter, non c'è problema a convertirle in proprietà normali in seguito.

Come hai detto, potresti usare i campi e se volessi aggiungere loro la logica in un secondo momento, li convertiresti in proprietà. Ma questo potrebbe presentare problemi con qualsiasi uso della riflessione (e forse altrove?).

Inoltre, le proprietà ti consentono di impostare diversi livelli di accesso per il getter e il setter che non puoi fare con un campo.

Immagino sia uguale alla parola chiave var. Una questione di preferenze personali.

Da Bjarne Stroustrup, creatore di C ++:

Non mi piacciono particolarmente le lezioni con molte funzioni get e set. Questo è spesso un'indicazione che non avrebbe dovuto essere una classe in primo luogo. È solo una struttura di dati. E se è davvero una struttura di dati, rendila una struttura di dati.

E tu sai cosa? Ha ragione. Quante volte stai semplicemente avvolgendo i campi privati ​​in get e set, senza realmente fare nulla all'interno di get / set, semplicemente perché è la cosa "orientata agli oggetti" da fare. Questa è la soluzione di Microsoft al problema; sono fondamentalmente campi pubblici ai quali puoi impegnarti.

Una cosa che nessuno sembra aver menzionato è come le proprietà automatiche non sono purtroppo utili per oggetti immutabili (di solito strutture immutabili). Perché per quello dovresti davvero fare:

private readonly string title;
public string Title
{
    get { return this.title; }
}

(dove il campo è inizializzato nel costruttore tramite un parametro passato e quindi è di sola lettura.)

Quindi questo ha dei vantaggi rispetto a una semplice get/ private setautoproperty.

Creo sempre proprietà anziché campi pubblici perché è possibile utilizzare proprietà in una definizione di interfaccia, non è possibile utilizzare campi pubblici in una definizione di interfaccia.

Le proprietà automatiche sono una magia nera quanto qualsiasi altra cosa in C #. Una volta che ci pensi in termini di compilazione fino a IL piuttosto che essere espansa in una normale proprietà C # prima è molta meno magia nera di molti altri costrutti di linguaggio.

Uso sempre le proprietà automatiche. Prima di C # 3 non potevo essere infastidito da tutta la digitazione e invece utilizzavo solo variabili pubbliche.

L'unica cosa che mi manca è riuscire a farlo:

public string Name = "DefaultName";

Devi spostare i valori predefiniti nei tuoi costruttori con proprietà. noioso :-(

Penso che qualsiasi costrutto intuitivo che riduca le righe di codice sia un grande vantaggio.

Questi tipi di funzionalità sono ciò che rende linguaggi come Ruby così potenti (che e funzionalità dinamiche, che aiutano anche a ridurre il codice in eccesso).

Ruby lo ha sempre avuto:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

L'unico problema che ho con loro è che non vanno abbastanza lontano. La stessa versione del compilatore che ha aggiunto proprietà automatiche, ha aggiunto metodi parziali. Il motivo per cui non hanno messo insieme i due è oltre me. Un semplice "parziale su <nome proprietà> modificato" avrebbe reso queste cose davvero utili.

È semplice, è breve e se si desidera creare una vera implementazione all'interno del corpo della proprietà da qualche parte lungo la linea, non si romperà l'interfaccia esterna del tipo.

Così semplice.

Una cosa da notare qui è che, per la mia comprensione, questo è solo zucchero sintattico sull'estremità di C # 3.0, il che significa che l'IL generato dal compilatore è lo stesso. Sono d'accordo sull'evitare la magia nera, ma comunque, meno righe per la stessa cosa di solito è una buona cosa.

A mio avviso, dovresti sempre utilizzare le proprietà automatiche anziché i campi pubblici. Detto questo, ecco un compromesso:

Inizia con un campo interno utilizzando la convenzione di denominazione che utilizzeresti per una proprietà. Anche tu la prima volta

• bisogno di accedere al campo dall'esterno del suo assemblaggio, o
• è necessario collegare la logica a un getter / setter

Fai questo:

1. rinominare il campo
2. renderlo privato
3. aggiungere una proprietà pubblica

Il tuo codice cliente non dovrà cambiare.

Un giorno, tuttavia, il tuo sistema crescerà e lo decomponi in assiemi separati e soluzioni multiple. Quando ciò accade, tutti i campi esposti torneranno a perseguitarti perché, come ha detto Jeff, cambiare un campo pubblico in una proprietà pubblica è una rottura dell'API .

Uso CodeRush, è più veloce delle proprietà automatiche.

Per fare questo:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Richiede un totale di otto sequenze di tasti.

Bene, con i frammenti di codice, una proprietà automatica con lo stesso nome sarebbe un totale di sette sequenze di tasti;)

@Domenic: non capisco .. non puoi farlo con le proprietà automatiche ?:

public string Title { get; }

o

public string Title { get; private set; }

È a questo che ti riferisci?

La mia più grande lamentela con le proprietà automatiche è che sono progettate per risparmiare tempo, ma spesso trovo che devo espanderle in proprietà complete in seguito.

Ciò che manca a VS2008 è un rifrattore di proprietà automatica esplodi .

Il fatto che abbiamo un refactor di campo incapsulato rende il mio modo di lavorare più veloce per usare solo i campi pubblici.