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

Entiendo las ventajas de las PROPIEDADES sobre los CAMPOS, pero creo que el uso de propiedades implementadas por AUTO sobre las propiedades implementadas MANUAL en realidad no proporciona ninguna ventaja más que hacer que el código sea 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 algún tipo de implementación personalizada de get y set, tengo que crear mi propia propiedad 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.

¿Esto solo 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.

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

Una ventaja del uso de autopropulsados ​​es que puede evitar que cometas un error de encoding tonta, como asignar accidentalmente la variable privada incorrecta a una propiedad. Confía en mí, lo he hecho antes!

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

No se garantiza que las propiedades implementadas automáticamente conserven el mismo nombre de campo de respaldo entre las comstackciones. Por lo tanto, es teóricamente posible que la serialización de 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 muy improbable, pero es una preocupación válida si intenta mantener la capacidad de “cambiar” la versión de sus ensamblajes por versiones más nuevas.

Al usar propiedades implementadas manualmente, se garantiza que el campo de respaldo nunca cambia (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.

Hay personas que piensan que las propiedades automáticas pueden ser algo malas, pero aparte de eso, son solo azúcar sintáctico. 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 progtwigción (imho).

Una de las cosas que perderá el control es la capacidad 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.

Olvidó: si usted o cualquier producto que utiliza realiza una reflexión sobre los miembros (es decir, WCF), verá el nombre del campo de respaldo mutilado en lugar de un campo de respaldo “bonito” que haya 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 del conducto 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: suponga que tiene un servicio web que expone algunos de sus objetos comerciales a través de WCF a un cliente 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.

No sé acerca de todos los demás, pero tiendo a detenerme un momento para pensar cómo denominar mis variables y funciones para que otros puedan entender mi código.

Entonces, cuando uso propiedades auto- implementadas, solo tengo que pausar una vez .

Cuando necesito un campo de respaldo , tengo que pausar dos veces , por lo que ralentiza el desarrollo un poco 🙂

La forma en que lo hago es:

  1. Convertirlo 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.

Una de las ventajas que veo al usar 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.