Propiedades autoejecutables C#

Question

1. alguien podría explicarme cuál es la idea detrás del uso de propiedades auto-implementadas C#?

   public class Customer 
   { 
       public int ID { get; set; } 
       public string Name { get; set; } 
   } 
   

   tengo la motivación para utilizar las propiedades de ámbito privado, por lo que puede determinar cómo se puede acceder a un campo privado. Pero aquí, es como definir que el campo sea público desde el primer lugar. ¿no?

2. ¿Hay alguna diferencia entre definir un campo como "const público" o definirlo para tener una propiedad de solo obtener?

Answer 1

Una propiedad pública automática no es lo mismo que un campo público, no son compatibles con binarios. Si implementa un campo público y luego desea agregar algo de lógica, deberá cambiarlo a una propiedad y, por lo tanto, introducir un cambio de rotura (debido a la incompatibilidad binaria). Esta es la razón por la cual muchas convenciones establecen que nunca debe exponer los campos públicos, sino más bien usar propiedades.

Por lo tanto, las propiedades automáticas son solo un punto de partida conveniente para cualquier miembro de clase simple no privado, lo que permite agregar lógica más adelante manteniendo la compatibilidad binaria.

Answer 2

Las propiedades se pueden unir a los datos, mientras que los campos no.

Answer 3

dejaré MSDN hacer hablar aquí ....

"En C# 3.0 y posterior, las propiedades implementadas automáticamente hacer de la propiedad-declaración más concisa cuando no se requiere lógica adicional en los descriptores de acceso. Ellos también permite que el código del cliente cree objetos. Cuando declara una propiedad como se muestra en el siguiente ejemplo (consulte el artículo de MSDN por ejemplo), el compilador crea un campo de respaldo privado y anónimo al que solo se puede acceder mediante los accessors de obtención y configuración de la propiedad "

Probablemente el di más ventajoso ferenc es que puede hacer la validación pre/post, aumentar PropertyChanged eventos etc

¿Hay una diferencia entre la definición de un campo para ser "public const" o definirla tener una propiedad para hacerse solamente?

Sí, un campo de solo recepción debe tener una declaración de campo privada. Este campo puede ser modificado por la clase internamente, marcando un campo como const significa que no se puede modificar.

Answer 4

2: una const pública se tiene que definir en tiempo de compilación, no se pueden usar objetos de referencia para eso. Sólo las clases que heredan de System.ValueType (cadena, int, double, ...)

una constante también es estático, mientras que una propiedad única con un captador no es (cada clase tiene su propia instancia.)

Answer 5

Con respecto a 1: se recomienda el uso de propiedades implementadas automáticamente, ya que puede implementar lógica adicional más adelante sin romper los cambios. Puede encontrar un ejemplo para esto en Learning about Auto-Implemented Properties

Answer 6

Las propiedades implementadas automáticamente son esencialmente azúcar sintáctico. Una vez compilado, existe la tienda de respaldo. Simplemente no está disponible desde el código fuente.

Como han indicado otros, las propiedades y los campos no son equivalentes. Los campos y las propiedades no son compatibles, por lo que cambiar entre ellos es un cambio radical. Además, no puede usar el enlace de datos con los campos.

Punto final. Aunque en su caso hay poca diferencia funcional entre el ejemplo y un campo público, puede cambiar la visibilidad de uno de los accesadores. Por lo tanto, para crear una propiedad de sólo lectura utilizando una propiedad automática, es posible hacer algo como:

public int ID { get; private set; } 

En este caso, el acceso get es público, como por toda la firma, pero el acceso set es privada.