¿Alguna razón para usar las propiedades implementadas automáticamente sobre las propiedades implementadas manualmente?

Question

Entiendo las ventajas de PROPIEDADES sobre CAMPOS, pero siento como si usar propiedades implementadas AUTOMÁTICAMENTE sobre las propiedades implementadas MANUAL en realidad no proporciona ninguna ventaja más que hacer el código un poco más conciso para verlo.

me siento mucho más cómodo usando:

private string _postalCode; 

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

En lugar de:

public string PostalCode { get; set; } 

principalmente porque si alguna vez quiero hacer cualquier tipo de implementación personalizada de obtener y definir, tengo que crear mi propiedad de todos modos respaldada por un campo privado. Entonces, ¿por qué no solo muerde la bala desde el principio y le das a todas las propiedades esta flexibilidad de inmediato, para mayor consistencia? Esto realmente no lleva sino un segundo extra, teniendo en cuenta que todo lo que tienes que hacer en Visual Studio es hacer clic en tu nombre de campo privado y presionar Ctrl + E, y listo. Y si lo hago de forma manual, entonces termino con una incoherencia en la que hay ALGUNAS propiedades públicas creadas manualmente respaldadas por campos privados, y ALGUNAS propiedades implementadas automáticamente. Me siento mucho mejor con todo lo que me rodea, ya sea automático o manual.

¿Soy yo? ¿Me estoy perdiendo de algo? ¿Me equivoco acerca de algo? ¿Estoy poniendo demasiado énfasis en la consistencia? Siempre puedo encontrar discusiones legítimas sobre las características de C#, y casi siempre hay ventajas y desventajas para todo, pero en este caso, realmente no pude encontrar a nadie que recomendara no usar las propiedades implementadas automáticamente.

Answer 1

No le concede nada más aparte de ser conciso. Si prefiere la sintaxis más verbosa, entonces por supuesto, use eso.

Una de las ventajas del uso de accesorios automáticos es que puede evitar que cometas un error de codificación como asignar accidentalmente la variable privada incorrecta a una propiedad. Confía en mí, lo he hecho antes!

Su punto acerca de que los accesorios automotrices no son muy flexibles es bueno. La única flexibilidad que tiene es usar private get o private set para limitar el alcance. Si sus captadores o instaladores tienen alguna complejidad para ellos, los accesorios automáticos ya no son una opción viable.

Answer 2

Hay personas que think that automatic properties can be somewhat evil pero aparte de eso son simplemente azúcar sintáctica. No se gana nada usándolos aparte de guardar algunas líneas de código y potencialmente puede crear más trabajo para usted (al tener que implementarlo manualmente más tarde porque quiere hacer alguna comprobación o plantear un evento). La consistencia es bastante valiosa en la programación (imho).

Answer 3

No sé sobre todos los demás, pero tienden a detenerse un momento a pensar en lo que debía nombrar mis variables de y funciones para que otros puedan entender mi código.

Así que cuando uso automóviles propiedades -implemented, sólo tienen que hacer una pausa, una vez.

Cuando necesito un campo respaldo tengo que hacer una pausa en dos tiempos, lo que frena la evolución un poco :)

La manera de hacerlo es:

1. la convierten en una variable privada en el inicio
2. Cámbielo público implementado automáticamente si es necesario.
3. Cámbielo al campo de respaldo si necesito algún código en get o set.

No hay nada de malo si las diferentes propiedades de una clase se exponen de manera diferente.

Answer 4

Una de las cosas que perderá el control es la posibilidad de especificar el campo de respaldo como No serializado, pero en este caso es bastante fácil crear un campo de respaldo para la propiedad.

He olvidado: si usted o cualquier producto que utilice realiza una reflexión sobre los miembros (es decir, WCF), verá el nombre de campo de respaldo mutilado en lugar del campo de respaldo "bonito" que ha creado.

Esto podría ser muy importante si anteriormente proporcionó acceso al servicio o si se deserializa en el extremo receptor en la misma estructura de clase (es decir, las mismas clases se utilizan en ambos extremos de la tubería WCF). En este caso, no necesariamente podría deserializar porque podría garantizar que el nombre del campo de respaldo sea el mismo a menos que comparta el mismo archivo DLL en lugar del código fuente.

Un poco más de aclaración: supongamos que tiene un servicio web que expone algunos de sus objetos comerciales a través de WCF a un cliente de Silverlight que ha creado. Para reutilizar su lógica comercial, su cliente de Silverlight agrega referencias al código fuente de sus objetos comerciales. Si tiene propiedades implementadas automáticamente, no tiene control sobre el nombre del campo de respaldo. Dado que WCF serializa los miembros y no las propiedades, no puede estar seguro de que el objeto transferido a silverlight desde el servicio WCF se deserializará correctamente, ya que los nombres de los campos de respaldo casi con seguridad no coincidirán.

Answer 5

Las propiedades implementadas automáticamente no garantizan que se mantenga el mismo nombre de campo de respaldo entre las compilaciones. Por lo tanto, es teóricamente posible que serializar un objeto en una versión de un ensamblaje, y luego volver a serializar ese mismo objeto en otro ensamblaje podría causar cambios bruscos.

Esto es altamente altamente improbable, pero es una preocupación válida si está tratando de mantener la capacidad de "cambiar" la versión de sus ensamblajes por versiones más nuevas.

Al usar las propiedades implementadas manualmente, tiene la garantía de que el campo de respaldo nunca cambiará (a menos que lo cambie específicamente).

Aparte de esa pequeña diferencia, una propiedad automática es una propiedad normal que se implementa automáticamente con un campo de respaldo.

Answer 6

Una de las ventajas que veo al utilizar propiedades automáticas es; al depurar la aplicación , no entrará en la sección Get/Set innecesaria. Sé que podemos evitar el mismo uso de Atributos del depurador o Paso a paso; sin embargo, sucede la mayoría de los casos si se debe depurar en una aplicación grande.