Qualche motivo per utilizzare le proprietà autoattive rispetto alle proprietà implementate manualmente?

Question

Comprendo i vantaggi di PROPERTIES over FIELDS, ma ho l'impressione che l'utilizzo di proprietà implementate da AUTO su proprietà implementate MANUAL non fornisca alcun vantaggio se non quello di rendere il codice un po 'più conciso per esaminarlo.

mi sento molto più comodo utilizzare:

private string _postalCode; 

    public string PostalCode 
    { 
     get { return _postalCode; } 
     set { _postalCode = value; } 
    } 

Invece di:

public string PostalCode { get; set; } 

in primo luogo perché se mai voglia di fare qualsiasi tipo di implementazione personalizzata di ottenere e impostare, devo creare la mia proprietà comunque sostenuta da un campo privato. Quindi, perché non mordere il proiettile dall'inizio e dare immediatamente tutte le proprietà a questa flessibilità, per coerenza? Questo in realtà non richiede un secondo in più, considerando che tutto ciò che devi fare in Visual Studio è fare clic sul tuo nome di campo privato e premere Ctrl + E, e il gioco è fatto. E se lo faccio manualmente, poi finisco con l'incoerenza in cui ci sono ALCUNE proprietà pubbliche create manualmente con il supporto di campi privati, e ALCUNE proprietà auto-implementate. Mi sento molto meglio con tutto ciò che è coerente in tutto, o tutto automatico o tutto manuale.

Sono solo io? Mi sto perdendo qualcosa? Mi sono sbagliato su qualcosa? Sto ponendo troppa enfasi sulla coerenza? Riesco sempre a trovare discussioni legittime sulle funzionalità di C#, e ci sono quasi sempre pro e contro su tutto, ma in questo caso, non sono riuscito a trovare nessuno a cui si consiglia di non utilizzare le proprietà implementate automaticamente.

Answer 1

Non ti concede nulla in più oltre a essere conciso. Se preferisci la sintassi più dettagliata, allora usa assolutamente quello.

Uno dei vantaggi dell'uso di ausili automatici è che può potenzialmente evitare di commettere un errore di programmazione sciocco, ad esempio l'assegnazione accidentale della variabile privata errata a una proprietà. Fidati di me, l'ho già fatto prima!

Il vostro punto di non essere molto flessibili è una buona idea. L'unica flessibilità disponibile è utilizzando private get o private set per limitare l'ambito. Se i tuoi getter o setter hanno una certa complessità per loro, gli oggetti di scena non sono più un'opzione praticabile.

Answer 2

Ci sono persone che sono think that automatic properties can be somewhat evil ma, a parte questo, sono solo zucchero sintattico. Non guadagni nulla usandoli oltre a salvare poche righe di codice e puoi potenzialmente creare più lavoro per te stesso (dovendo implementarlo manualmente comunque in seguito perché vuoi fare un controllo o un evento). La coerenza è abbastanza utile nella programmazione (imho).

Answer 3

Non so su tutti gli altri, ma io tendo a mettere in pausa un momento per pensare cosa devo chiamare i miei variabili e funzioni modo che altri possano capire il mio codice.

Così quando uso auto proprietà -implemented, Ho solo per mettere in pausa una volta.

Quando ho bisogno di un campo supporto devo mettere in pausa due volte, in modo che rallenta lo sviluppo un po ':)

Il modo in cui lo faccio è:

1. Ne fanno una variabile privata all'inizio
2. Cambiare l'auto-implementazione pubblica se necessario.
3. Passa al campo di supporto se ho bisogno di un codice in get o set.

Non c'è niente di sbagliato se diverse proprietà di una classe sono esposte in modo diverso.

Answer 4

Una delle cose che si perde il controllo è la possibilità di specificare il campo di supporto come Non serializzato, ma in questo caso è abbastanza facile creare un campo di supporto per la proprietà.

Dimenticato: se tu o qualsiasi prodotto che usi esegue la riflessione sui membri (cioè WCF), allora vedrai il nome del campo di appoggio storpiato invece di un campo "carino" che hai creato.

Questo potrebbe essere molto importante se si era precedentemente fornito l'accesso al servizio o se si deserializza sul lato ricevente nella stessa struttura di classe (ad esempio, le stesse classi vengono utilizzate su entrambe le estremità della pipe WCF). In questo caso, non sarà necessariamente possibile deserializzare perché è possibile garantire che il nome del campo di supporto sia lo stesso, a meno che non si condivida la stessa DLL anziché il codice sorgente.

Un po 'più di chiarimento: si supponga di disporre di un servizio Web che espone alcuni oggetti di business su WCF a un client Silverlight che è stato creato. Per riutilizzare la logica aziendale, il client Silverlight aggiunge riferimenti al codice sorgente per i propri oggetti di business. Se si dispone di proprietà autoattive, non si ha alcun controllo sul nome del campo di supporto. Poiché WCF serializza i membri e non le proprietà, non è possibile essere certi che l'oggetto trasferito su silverlight dal servizio WCF verrà deserializzato correttamente poiché i nomi dei campi di supporto saranno quasi certamente non corrispondenti.

Answer 5

Le proprietà di implementazione automatica non sono garantite per mantenere lo stesso nome del campo di supporto tra le build. Pertanto, è teoricamente possibile che la serializzazione di un oggetto in una versione di un assieme e quindi la serializzazione ripetuta di quello stesso oggetto in un altro assieme possa causare modifiche irreversibili.

Questo è altamente improbabile, ma è un problema valido se si sta tentando di mantenere la possibilità di "scambiare" la versione degli assembly per le versioni più recenti.

Utilizzando le proprietà implementate manualmente, è garantito che il campo di supporto non cambia mai (a meno che non lo si modifichi in modo specifico).

A parte questa piccola differenza, una proprietà automatica è una proprietà normale che viene implementata automaticamente con un campo di supporto.

Answer 6

Uno dei vantaggi che vedo utilizzando le proprietà auto è; durante il debug dell'applicazione non entrerà nella sezione Get/Set non necessaria. So che possiamo evitare lo stesso usando Debugger Attributes o Step over; tuttavia accade nella maggior parte dei casi se esegui il debug su una grande applicazione.