No pude entender por qué la característica de lenguaje de propiedad implementado automáticamente existe en C# 3.0.Diferencia entre las propiedades automáticas y el campo público en C# 3.0
Lo que la diferencia que está haciendo cuando dicen
public string FirstName;
que
public string FirstName { get; set; }
Debido a que se implementan de forma diferente en el código resultante IL (y lenguaje de máquina). Una propiedad automática sigue estando expuesta como getter y setter públicos, mientras que un campo público es solo eso: un solo campo ...
Por lo tanto, la implementación de una propiedad automática le permite en algún momento cambiar el comportamiento interno de cualquiera getter o setter (como agregar un validador) sin recompilar o volver a codificar ninguna clase dependiente que lo use ...
Además, puede usar propiedades para enlace de datos. –
El primero es un campo público, mientras que el segundo es una propiedad pública.
La principal diferencia radica en cómo se usan. Por ejemplo, WPF solo puede enlazar datos a propiedades, no a campos.
La diferencia es que otros ensamblados compilados con código que leen la propiedad se compilan contra una propiedad.
Si más adelante decide que necesita agregar código al captador o al colocador, puede hacerlo sin tener que forzar a los demás ensamblados para recompilarlo.
No es así con los campos. Si más adelante cambia un campo para que sea una propiedad, para agregar ese código, otros ensamblajes vinculados con los suyos dejarán de funcionar correctamente, ya que están compilados para leer un campo, no una propiedad.
Además, se escribe mucho código para encontrar propiedades, no campos, como el enlace de datos y similares.
Considere lo que sucede si luego desea cambiar cada una de ellas a una propiedad con una implementación personalizada. Si se trata de una propiedad implementada automáticamente, simplemente agrega un campo y cambia la implementación. Completa compatibilidad de fuente y binario.
Si es un campo para empezar, no obtienes ni la fuente ni la compatibilidad binaria. Tienes que reconstruir todo lo que hace referencia a él, y arreglar todo lo que ya no compila.
Además, properties have various benefits over fields. Mi principal objeción personal a los campos es que expone una decisión de implementación en la API.
Solo para agregar a lo que otras personas han dicho, al declarar un campo público, el campo es accesible para lectura y escritura. declarando propiedad pública automática, aunque la propiedad es pública, puede agregar modificador para controlar la accesibilidad en el nivel get/set.
public string FirstName { get; private set; }
El usuario de su clase ve el Nombre como propiedad pública. Sin embargo, él/ella no puede escribir en él.
Debido a este uso:
public string FirstName { get; private set; }
propiedad fácil, que 'kosher' por OO reglas
propiedades de auto son compilador genera propiedades regulares, que utilizan un soporte campos como cualquier propiedad regular, pero que no lo hacen necesita escribir el código para eso. Este es un ejemplo muy ilustrativo (gracias a Reflector) del código generado por el compilador:
[CompilerGenerated]
private string <ContentType>k__BackingField;
public string ContentType
{
[CompilerGenerated]
get
{
return this.<ContentType>k__BackingField;
}
[CompilerGenerated]
set
{
this.<ContentType>k__BackingField = value;
}
}
Nadie fuera de Microsoft utiliza el nombre en clave una vez que el producto va RTM. –
posible duplicado de [Diferencia entre propiedad y campo en C# 3.0+] (http://stackoverflow.com/questions/653536/difference-between-property-and-field-in-c-sharp-3-0) – nawfal
All las respuestas aquí me parecen indicar el hecho de que esto es un defecto en el diseño del lenguaje. Seguramente los problemas aquí podrían resolverse en el compilador o en el nivel de tiempo de ejecución. ¿Por qué tiene que romper la compatibilidad binaria y de origen? ¿Por qué nos vemos obligados a agregar un texto repetitivo que podría optimizarse? –