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

En C# puede crear captadores/definidores de una manera más simple que otros idiomas:¿Con qué frecuencia ve abuso de captadores/setters de taquigrafía C#?

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 ve esto maltratado? Parece que tiene un alto potencial para violar a menudo las mejores prácticas de encapsulación. No me malinterprete, lo uso como corresponda, y variaciones parciales de él para los tipos de propiedades solo de escritura de solo lectura, pero ¿cuáles son sus experiencias desagradables con él de otros autores en su base de códigos?

Aclaración: la definición intencionada de abuso sería crear tal propiedad cuando las variables privadas son apropiadas.

Fuente

2009-07-02 Ben Lakey

Abusados cómo exactamente? la única cosa abusiva que puedo pensar es poner el valor de un método de trabajo en una propiedad, y eso es bastante menor – annakata

¿Podría dar un ejemplo en el que piense que el uso de propiedades automáticas no es apropiado? –

@annakata - que ** no puede ** hacer con una propiedad implementada automáticamente. –

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

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

van a veces escribir:

public int Foo { get; private set; }

sí, es más corto. Sí, desde fuera de la clase tiene la misma apariencia, pero no los veo como la misma cosa, ya que la última forma permite que la propiedad se establezca en otra parte de la misma clase. También significa que no hay advertencia si la propiedad no está configurada en el constructor, y el campo no es de solo lectura para el CLR. Estas son diferencias sutiles, pero ir por la segunda forma porque es más simple e ignorar las diferencias me parece un abuso, incluso si es menor.

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; }

Fuente

2009-07-02 09:33:07

Buen punto. También me gustaría ver solo para las propiedades automáticas – BengtBe

. He visto esto comúnmente también, pero tu opinión es interesante. –

No es casi lo mismo, porque marcó la variable local foo como de solo lectura. Si es de solo lectura, no se puede configurar en ningún otro lugar como en la primera inicialización, si no, se puede acceder desde otra parte en la misma clase, como la última forma de ti. –

No existe un "abuso" simplemente al no escribir el campo manualmente; y es bueno alentar todo acceso a través de la propiedad (¡no directamente al campo) de todos modos!

El problema más grande que conozco es con binary serialization, 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 ... utilizar un serializador diferente ;-P

Sería bueno si hubiera una variante readonly "correcta", y si no necesitara usar :this() ctor-encadenando en las estructuras, pero ... ¡meh!

Fuente

2009-07-02 09:31:20

Estoy de acuerdo. Creo que las propiedades pueden ayudar a extender las cosas más adelante (especialmente si son públicas y espera que otra persona use sus clases). – Ian

Siga el puntero de instrucciones de rebote aquí (;)): propiedades automáticas, no puede acceder a sus tiendas de respaldo. Si es solo así, entonces no hay manera de darle un valor * en absoluto *. Por lo tanto, sería inútil ... – RCIX

@RCIX: la idea sería declararlo como un conjunto privado, pero use un '[Readonly]' para forzar que este acceso se restrinja exactamente como 'readonly'. –

No he visto ningún abuso de él. Y para ser honesto, realmente no entiendo a qué te refieres, ya que no puedo ver cómo se puede abusar de esta sintaxis.

Fuente

2009-07-02 09:31:35 Razzie

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 campos privados en lugar entonces esto es por supuesto mal y se rompe la encapsulación ..

Fuente

2009-07-02 09:33:23 BengtBe

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

Respuesta

Cuestiones relacionadas