¿Con qué frecuencia se ve el abuso de C # taquigrafía getters / setters?

Question

En C # puede crear captadores / definidores de una manera más simple que otros idiomas:

public int FooBar { get; set; }

Esto crea una variable privada interna que no se puede abordar directamente, con la propiedad externa 'FooBar' para acceder a ella directamente.

Mi pregunta es - ¿Con qué frecuencia se ve este maltratado? Parece que tiene un alto potencial para violar las mejores prácticas de encapsulación a menudo. No me malinterpreten, lo uso en su caso, y las variaciones parciales de la misma para sólo lectura de sólo escritura tipos de propiedades, pero ¿cuáles son sus experiencias desagradables con los de otros autores en su base de código?

Aclaración:. La definición prevista del abuso de hecho sería la creación de este tipo de propiedad privada cuando las variables son apropiados

Answer 1

Lo he visto abusado (en mi opinión). En particular, cuando el desarrollador normalmente de escritura:

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

a veces voy a escribir:

public int Foo { get; private set; }

Sí, es más corto. Sí, desde fuera de la clase que tiene la misma apariencia - pero no ver esto como la misma cosa, como la última forma permite que la propiedad que se establece en otro lugar en la misma clase. También significa que no hay ninguna advertencia si la propiedad no está establecida en el constructor, y el campo no es de sólo lectura para el CLR. Estas son diferencias sutiles, pero sólo va para la segunda forma porque es más simple y haciendo caso omiso de las diferencias se siente como el abuso a mí, incluso si es menor de edad.

Afortunadamente, esto es ahora disponible a partir de C # 6:

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

Answer 2

No hay un "abuso" en simplemente no escribir manualmente el campo; y es bueno para animar a todos los accesos a través de la propiedad (no directamente al campo) de todos modos!

El problema más grande que conozco es con serialización binaria , donde se pone un poco difícil de cambiar de nuevo a un campo regular sin por lo que es incompatible con la versión - pero entonces ... ;-P utilizar un serializador diferente

Sería bueno si había una variante de sólo lectura "correcta", y si no es necesario utilizar :this() ctor en cadena de estructuras, pero .... meh!

Answer 3

No he visto ningún abuso de ella. Y para ser honesto, realmente no lo que quiere decir, ya que no puedo ver cómo esta sintaxis podría ser objeto de abuso.

Answer 4

No creo propiedades automáticas son peores que las propiedades regulares en lo que respecta a la encapsulación.

Si se refiere a que algunos desarrolladores utilizan propiedades automáticas públicos en lugar campos privados, entonces esto es por supuesto mal y se rompe la encapsulación ..