Diferencia entre propiedad y campo en C# 3.0+
Me doy cuenta de que parece ser un duplicado de ¿ Cuál es la diferencia entre un campo y una propiedad en C#? pero mi pregunta tiene una ligera diferencia (desde mi punto de vista):
Una vez que sé eso
- No usaré mi clase con "técnicas que solo funcionan en propiedades" y
- No usaré código de validación en el getter/setter.
¿Hay alguna diferencia (excepto las de estilo/desarrollo futuro), como algún tipo de control en la configuración de la propiedad?
¿Existe alguna diferencia adicional entre:
public string MyString { get; set; }
y
public string myString;
(Soy consciente de que la primera versión requiere C# 3.0 o superior y que el compilador crea los campos privados).
Los campos y las propiedades parecen iguales, pero no lo son. Las propiedades son métodos y, como tales, hay ciertas cosas que no son compatibles con las propiedades y algunas cosas que pueden suceder con las propiedades, pero nunca en el caso de los campos.
Aquí hay una lista de diferencias:
- Los campos se pueden utilizar como entrada para
out/refargumentos. Las propiedades no pueden. - Un campo siempre producirá el mismo resultado cuando se llame varias veces (si dejamos de lado los problemas con varios subprocesos). Una propiedad tal como
DateTime.Nowno siempre es igual a sí misma. - Las propiedades pueden generar excepciones; los campos nunca harán eso.
- Las propiedades pueden tener efectos secundarios o tardar mucho en ejecutarse. Los campos no tienen efectos secundarios y siempre serán tan rápidos como se pueda esperar para el tipo determinado.
- Las propiedades admiten diferente accesibilidad para captadores/definidores; los campos no (pero se pueden crear campos
readonly) - Cuando se utiliza la reflexión, las propiedades y los campos se tratan como diferentes,
MemberTypespor lo que se ubican de manera diferente (GetFieldsvs,GetPropertiespor ejemplo). - El compilador JIT puede tratar el acceso a propiedades de manera muy diferente en comparación con el acceso a campos. Sin embargo, puede compilarse en código nativo idéntico, pero el margen de diferencia está ahí.
Encapsulación.
En el segundo caso, acaba de definir una variable; en el primero, hay un captador/definidor alrededor de la variable. Entonces, si decide que desea validar la variable en una fecha posterior, será mucho más fácil.
Además, aparecen de forma diferente en Intellisense :)
Editar: Pregunta actualizada de actualización para OP: si desea ignorar las otras sugerencias aquí, la otra razón es que simplemente no es un buen diseño de OO. Y si no tiene una muy buena razón para hacerlo, elija siempre una propiedad en lugar de una variable/campo público.
