Quante volte si vedono abuso di C # stenografia getter / setter?

Question

In C # è possibile creare getter / setter in un modo più semplice di altre lingue:

public int FooBar { get; set; }

Questo crea una variabile privata interna che non si può affrontare direttamente, con la proprietà esterna 'FooBar' per accedere direttamente.

La mia domanda è - come spesso si vede questo abusato? Sembra che ha un alto potenziale di violare l'incapsulamento best practice spesso. Non fraintendetemi, io lo uso a seconda dei casi, e le variazioni parziali di esso in sola lettura sola scrittura tipi di proprietà, ma quali sono le tue esperienze spiacevoli con esso da altri autori nel codice di base?

Chiarimento:. La definizione prevista di abuso sarebbe davvero essere la creazione di una tale proprietà quando le variabili private sono appropriate

Answer 1

L'ho visto abusato (a mio parere). In particolare, quando lo sviluppatore avrebbe normalmente di scrittura:

private readonly int foo;
public int Foo
{ 
    get 
    { 
        return foo;
    }
}

faranno a volte scrivono:

public int Foo { get; private set; }

Sì, è più breve. Sì, al di fuori della classe ha lo stesso aspetto - ma io non vedere questi come la stessa cosa, in quanto quest'ultimo modulo permette la proprietà da impostare altrove nella stessa classe. Questo significa anche che non c'è alcun avviso se la proprietà non è impostata nel costruttore, e il campo non è di sola lettura per il CLR. Questi sono sottili differenze, ma solo andando per la seconda forma, perché è più semplice e ignorando le differenze si sente come l'abuso a me, anche se è minore.

Per fortuna, questo è ora disponibile a partire da C # 6:

// Foo can only be set in the constructor, which corresponds to a direct field set
public int Foo { get; }

Answer 2

Non c'è un "abuso" in semplicemente non scrivere il campo manualmente; ed è bene per incoraggiare tutti gli accessi tramite la proprietà (non direttamente al campo) in ogni caso!

Il problema più grande che conosco è con serializzazione binaria , dove ottiene un po 'difficile da cambiare di nuovo ad un campo regolare, senza farne versione incompatibile - ma poi ... utilizzare un diverso ;-p serializzatore

Sarebbe bello se ci fosse un "adeguato" variante sola lettura, e se non hai bisogno di usare :this() ctor-chaining su struct, ma .... meh!

Answer 3

Non ho visto qualsiasi abuso di esso. E ad essere onesti, io non vedo proprio che cosa vuoi dire, come non riesco a vedere come potrebbe essere abusata questa sintassi.

Answer 4

Non credo proprietà automatici sono peggio di proprietà regolari in materia di incapsulamento.

Se vuoi dire che alcuni sviluppatori di utilizzare le proprietà automatiche pubblici invece campi privati, allora questo è naturalmente sbagliato e si rompe l'incapsulamento ..