Desventajas del uso de propiedades solo sin los campos correspondientes en .NET?

Question

Tengo clases que tienen propiedades automáticas solo como public customerName {get; conjunto;}. Son públicos porque se accede fuera de la clase. También se puede acceder dentro de la clase. Ofrecen una buena encapsulación y una mejor depuración. Puedo poner un punto de inflexión en uno si necesito saber quién está accediendo a él y cuándo.

Mi pregunta es ¿cuáles son las desventajas de usar propiedades solo sin campos correspondientes? Puedo hacer que setter o getter sean privados, internos, etc., lo que significa que también tengo la flexibilidad de analizarlos cuando sea necesario.

Answer 1

serialización con BinaryFormatter - usted tiene grandes problemas si necesita cambiar su propiedad a una propiedad "regular", más adelante, por ejemplo, para añadir un poco de validación/concurso completo/etc - SINC BinaryFormatter utiliza los nombres de los campos. Y no puede duplicar esto, ya que el nombre de campo que genera el compilador no se puede escribir como C# legal.

Cuál es una buena razón para mirar un serializador basado en contrato en su lugar. Vea this blog entry para más información.

Answer 2

No hay inconvenientes para las propiedades simples. El compilador crea el campo de respaldo para usted. Este blog entry explica cómo trata el compilador las propiedades implementadas automáticamente.

Answer 3

El problema es que es y corresponde al campo correspondiente. Simplemente no lo ves porque el compilador lo crea por ti. Las propiedades automáticas son solo azúcar sintáctico o forma abreviada para crear el campo.

Answer 4

No se puede crear realmente solo leer propiedad, porque debe definir setter y getter. Solo puede usar el ajustador privado para lograr una propiedad pseudo-readonly desde el exterior.

De lo contrario, como se dijo anteriormente, no hay otras desventajas.

Answer 5

No hay cosas importantes. Simplemente marque mayúsculas y minúsculas como si necesita pasar una propiedad a un método donde el parámetro se pasa por referencia (ref o out) que no es posible con una propiedad (porque internamente, solo son métodos get_Property/set_Property implementados por el compilador , no campos especiales de algún tipo) y necesitaría un campo de respaldo privado explícito para esto.

EDITAR: Ah, y secundando las propiedades 'no readonly', que en realidad es bastante común.

Answer 6

Si no es necesario realizar ninguna lógica específica en el get y/o descriptores de acceso establecidos, no hay inconveniente ...

Answer 7

digo que son malos desde el punto de vista legibilidad del código. El azúcar de sintaxis es bueno para escribir código pero es horrible para leer el código. Como desarrolladores, el código que dejamos será en última instancia heredado por un desarrollador deficiente que tendrá que entender lo que hicimos y lo que está sucediendo en el código. Realmente estoy en contra de cambiar un idioma para simplemente guardar las pulsaciones de teclas cuando hay una sintaxis establecida para las mismas construcciones.

Answer 8

No es realmente una desventaja, pero debe tener en cuenta los valores predeterminados de las propiedades automáticas. Con las propiedades "clásicas" siempre utilizamos para inicializar los campos de respaldo, p. como este:

private bool _flag = true; 
public bool Flag 
{ 
    get { return _flag; } 
    set { _flag = value; } 
} 

Esto hizo obvio cuál es el valor predeterminado de la propiedad.

Con propiedades automáticas, debe saber cuáles son los valores predeterminados para los diferentes tipos (por ejemplo, falso para bool). Si no desea que la propiedad que tiene el valor por defecto que tiene que inicializar en el constructor:

class MyClass 
{ 
    public bool Flag { get; set; } 
    public MyClass() 
    { 
    Flag = true; 
    } 
} 

Esto significa, que tiene que implementar un constructor si desea inicializar sus propiedades a no predeterminado valores o si una propiedad es de un tipo de referencia (clase).

Pero como escribí, realmente no pienso en esto como una desventaja, solo algo que debes saber.