sirve - propiedades publicas c#
¿Por qué usar propiedades simples en lugar de campos en C#? (5)
Principalmente por convención.
El único argumento sólido para esto es que si luego necesita cambiar de un campo a una propiedad, entonces todos los ensamblajes que hagan referencia al suyo necesitarán ser recompilados.
La reflexión entra de vez en cuando, pero muy raramente. Algunos tipos de serialización están basados en propiedades.
Posibles duplicados:
¿Debo usar propiedades públicas y campos privados o campos públicos para datos?
Diferencia entre las propiedades automáticas y el campo público en C # 3.0
La gente parece insistir dogmáticamente en el uso de propiedades públicas sobre los campos, pero ¿por qué es tan importante en el caso de las propiedades simples?
Como es
public int Foo { get; set; }
tan increíblemente diferente que
public int Foo;
?
En lo alto de mi cabeza, puedo pensar en algunas diferencias prácticas entre los dos:
- Acceder al miembro mediante el uso de la reflexión (los algoritmos raros y la mayoría de los decentes reflejarán la diferencia)
- La segunda entrada le permite usar el campo como un parámetro válido para los parámetros de ref y out, lo que parecería ser una ventaja al usar la versión de campo
- Los campos no funcionan en Remoting (probablemente, nunca he usado la comunicación remota, pero me imagino que no).
Además de estos casos bastante raros, cambiar Foo para que sea una propiedad calculada más tarde da como resultado la modificación de 0 líneas de código.
Puede hacer que las propiedades sean virtuales y anular su implementación en clases derivadas. Este es un factor importante en muchas bibliotecas que envuelven sus objetos en clases proxy generadas, por ejemplo, la forma en que NHibernate implementa la carga diferida. Esto no es posible en los campos.
Una buena razón es que puedes variar la accesibilidad get / set.
public int Foo {get; protected set;}
Una propiedad es un elemento de lenguaje que lógicamente representa una propiedad de la cosa modelada por la clase . La clase Coche modela un automóvil; el color es una propiedad de los automóviles; por lo tanto, el Color es una propiedad de Car.
Un campo es un elemento de lenguaje que representa un detalle de implementación de la clase . Su automóvil no tiene un "campo de color", por lo que la representación de un automóvil en su programa no debe exponer un campo llamado Color. Puede contener un detalle de implementación privado mediante el cual el color de la propiedad es implementado por un campo, pero es un detalle de implementación privado, no una parte del modelo accesible al público.
Usar propiedades tiene un par de ventajas distintas:
- Permite el control de versiones si luego necesita una lógica adicional. Agregar lógica al getter o al setter no romperá el código existente.
- Permite que el enlace de datos funcione correctamente (la mayoría de los marcos de enlace de datos no funcionan con los campos).
Además, casi no hay desventajas. Las propiedades simples y automáticas como esta son incorporadas por el compilador JIT, por lo que no hay razón para no usarlas.
Además, usted mencionó:
Además de estos casos bastante raros, cambiar Foo para que sea una propiedad calculada más tarde da como resultado la modificación de 0 líneas de código.
Esto no requiere que se modifique su código, pero sí obliga a recompilar todo su código. Cambiar de un campo a una propiedad es un cambio brusco de API que requerirá la recompilación de cualquier ensamblado que haga referencia a su ensamblaje. Al convertirlo en propiedad automática, puede enviar un nuevo archivo binario y mantener la compatibilidad API. Esta es la ventaja de "control de versiones" que mencioné anteriormente ...