C# 3.0 auto-proprietà — utile o no?[chiuso]

Question

Nota:Questo è stato postato quando ho iniziato a C#.Con il 2014, di conoscenza, posso veramente dire che le auto di proprietà, sono tra le cose migliori che sia mai capitata al linguaggio C#.

Ho utilizzato per creare la mia proprietà in C# utilizzando un privato e un campo pubblico:

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

Ora, con .NET 3.0, ci siamo auto-proprietà:

public string Title { get; set; }

So che questo è più filosofico/domande soggettive, ma c'è qualche motivo per utilizzare questi auto-proprietà, ad eccezione di salvare cinque righe di codice per ogni campo?Il mio personale cruccio è che tali proprietà si nascondono roba da me, e io non sono un grande fan di magia nera.

Infatti, nascosto campo privato non è neanche nel debugger, che è OK, dato il fatto che il get/set di funzioni non fare nulla.Ma quando voglio effettivamente implementare alcuni metodi getter/setter, devo usare l'pubblico-privato, di coppia comunque.

Vedo il beneficio che risparmiare un sacco di codice (uno contro sei righe) senza perdere la capacità di modificare le proprietà getter/setter più tardi, ma poi di nuovo, posso già farlo semplicemente dichiarare un campo pubblico "Public string Titolo" senza la necessità di { get;set;} blocco, quindi anche il risparmio di più di codice.

Così, quello che mi manca qui?Perché qualcuno dovrebbe voler utilizzare auto-proprietà?

Answer 1

Li usiamo per tutto il tempo in Overflow dello Stack.

Si può anche essere interessati a una discussione Proprietà vs.Le Variabili Pubbliche.IMHO è proprio quello che questa è una reazione, e, a tale scopo, è grande.

Answer 2

Sì, è una cosa solo salvare il codice.È miglia più facile da leggere quando si hanno un sacco di loro.Sono veloce a scrivere e più facile da mantenere.Salvare il codice è sempre un buon obiettivo.

È possibile impostare diversi ambiti:

public string PropertyName { get; private set; }

In modo che la proprietà può essere modificata solo all'interno della classe.Questa non è immutabile, come si può ancora accedere al privato setter attraverso la riflessione.

Come di C#6 è inoltre possibile creare un vero readonly proprietà - cioèimmutabile proprietà che non può essere modificato al di fuori del costruttore:

public string PropertyName { get; }

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

In fase di compilazione che diventerà:

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

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

Nell'immutabile classi con un sacco di membri ciò consente di risparmiare un sacco di eccesso di codice.

Answer 3

Le tre grandi svantaggi di utilizzando invece i campi di proprietà sono:

1. Non è possibile databind a un campo che non si può per una proprietà
2. Se si avvia utilizzando un campo, non è possibile poi (facilmente) modificare una proprietà
3. Ci sono alcuni attributi che è possibile aggiungere a una proprietà che non è possibile aggiungere a un campo

Answer 4

Io personalmente amo auto di proprietà.Cosa c'è di sbagliato con il salvataggio dell'righe di codice?Se vuoi fare le cose nel getter o setter, non c'è nessun problema per la conversione normale proprietà in seguito.

Come hai detto tu si potrebbe utilizzare i campi, e se si vuole aggiungere la logica per loro più tardi, devi convertirli in proprietà.Ma questo potrebbe presentare problemi con l'eventuale utilizzo di riflessione (e forse altrove?).

Anche le proprietà che consentono di impostare diversi livelli di accesso per i metodi getter e setter che non si può fare con un campo.

Credo che la parola chiave var.Una questione di preferenze personali.

Answer 5

Da Bjarne Stroustrup, il creatore del C++:

Io in particolare avversione per le classi con un sacco di le funzioni get e set.Che è spesso un'indicazione che non sono stati di una classe, in primo luogo.È solo una struttura di dati.E se davvero è una struttura di dati, ne fanno una struttura di dati.

E sapete una cosa?Ha ragione.Quante volte vi è semplicemente avvolgendo campi privati in get e set, senza in realtà fare nulla all'interno di get/set, semplicemente perché è la "object oriented" cosa da fare.Microsoft soluzione al problema;sono sostanzialmente dei campi pubblici che si possono associare.

Answer 6

Una cosa che nessuno sembra avere accennato è come auto-proprietà non sono, purtroppo, utile per gli oggetti immutabili (di solito immutabile struct).Perché per che si dovrebbe 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 un semplice get/private set autoproperty.

Answer 7

Ho sempre creare proprietà invece di campi pubblici, perché è possibile utilizzare le proprietà nella definizione di un'interfaccia, non è possibile utilizzare i campi pubblici nella definizione di un'interfaccia.

Answer 8

Auto-proprietà: un magia nera, come qualsiasi altra cosa in C#.Una volta che la pensate in termini di compilazione giù per IL invece di essere ampliato per un normale C# la proprietà prima è molto meno magia nera di un sacco di altri costrutti del linguaggio.

Answer 9

Io uso auto-proprietà per tutto il tempo.Prima di C#3 non potevo essere disturbato con tutta la digitazione e solo usato le variabili pubbliche, invece.

L'unica cosa che mi manca è poter fare questo:

public string Name = "DefaultName";

È necessario cambiare i valori di default nel tuo costruttori con la proprietà.noioso :-(

Answer 10

Penso che qualsiasi costruzione che è intuitivo E riduce le linee di codice è un grande vantaggio.

Questi tipi di caratteristiche sono ciò che rende linguaggi come Ruby così potente (che e caratteristiche dinamiche, che aiutano anche a ridurre l'eccesso di codice).

Ruby ha avuto tutto questo lungo come:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Answer 11

L'unico problema che ho con loro è che essi non andare abbastanza lontano.La stessa versione del compilatore che ha aggiunto di proprietà automatico, aggiunto parziale metodi.Perché non mettere insieme le due cose è al di là di me.Un semplice "parziale Sul<PropertyName>Cambiato" avrebbe fatto queste cose davvero utili.

Answer 12

E ' semplice, è breve e, se si desidera creare una reale attuazione all'interno della proprietà, il corpo da qualche parte lungo la linea, non rompere il vostro tipo di interfaccia esterna.

Semplice come quello.

Answer 13

Una cosa da notare qui è che, a mio parere, questo è solo zucchero sintattico in C# 3.0 fine, il che significa che il generato dal compilatore è lo stesso.Concordo sull'evitare di magia nera, ma tutti uguali, un minor numero di righe per la stessa cosa di solito è una buona cosa.

Answer 14

A mio parere, si dovrebbe sempre utilizzare auto-proprietà invece di campi pubblici.Detto questo, ecco un compromesso:

Iniziare con un interno campo utilizzando la convenzione di denominazione che si potrebbe utilizzare per una proprietà.Quando si prima

• la necessità di accedere al campo da al di fuori della sua assemblea, o
• è necessario collegare la logica di un getter/setter

Fare questo:

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

Il codice del client non è necessario cambiare.

Un giorno, però, il vostro sistema sarà crescere e ti scomponi in separate assemblee e più soluzioni.Quando ciò accade, esposti campi tornerà a ritorcersi contro di te, perché, come ha già detto Jeff, la modifica di un campo pubblico di una proprietà pubblica è una rottura di modifica dell'API.

Answer 15

Io uso CodeRush, è più veloce di auto-proprietà.

Per fare questo:

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

Richiede otto battute totale.

Answer 16

Bene con gli snippet di codice di una funzione di una proprietà con lo stesso nome sarebbe sette sequenze di tasti in totale ;)

Answer 17

@Domenico :Non la capisco..non si può fare questo con auto-di proprietà?:

public string Title { get; }

o

public string Title { get; private set; }

E ' questo quello a cui ti riferisci?

Answer 18

La mia più grande lamentela con auto-di proprietà che consente di risparmiare tempo, ma spesso mi trovo a espandere in piena regola proprietà in seguito.

Cosa VS2008 manca è un Esplodere L'Auto Di Proprietà il refactoring.

Il fatto che abbiamo un incapsulare campo refactor rende il mio lavoro più veloce per utilizzare solo i campi pubblici.