Propiedad (sin procesamiento adicional) vs campo público

Question

Siempre que haya dudas sobre la credibilidad de Properties, veo que la mayor parte de la discusión tiene lugar en funciones/métodos frente a propiedades. Pero también me gustaría saber el convincente razón para usar la propiedad con el campo privada asociada vs ámbito público directamente en sí, en caso de comportamientos get/set más comunes con los tratamientos siguientes, me refiero a esta forma

public string CustomerName; 

vs

private string customerName; 
public string CustomerName 
{ 
get{return customerName;} 
set(string value){this.customerName=value;} 
} 

Answer 1

usted obtiene fuente/compatibilidad binaria si más adelante necesita añadir otro comportamiento, se llega a añadir puntos de ruptura, y es simplemente filosóficamente más limpia (atención sobre el comportamiento, no el mecanismo de almacenamiento).

Tenga en cuenta que no es necesario el conjunto del último bloque en C# 3:

public string CustomerName { get; set; } 

Ver my article on "Why Properties Matter" para más información.

Answer 2

1. Puede anular o al menos crear una "nueva" propiedad en una clase derivada

2. En este punto, la gente espera que las propiedades sean expuestos y los campos que se oculta. Si alguien va a reflexionar sobre su clase (cada vez es más común con herramientas como Castle Windsor, NHibernate), hay un mundo de diferencia, es probable que no estén buscando campos expuestos.

Answer 3

También puede proporcionar una validación básica con propiedades. Por ejemplo, para prevenir el establecimiento de una propiedad a un estado no válido como un valor negativo para una altura:

private int height; 
public int Height 
{ 
    get{ return height; } 
    set 
    { 
    if (value > 0) 
    { 
     height = value; 
    } 
    } 
} 

Answer 4

Esto es sobre todo un error en Java. En muchos otros lenguajes (Python, Delphi, Groovy), el compilador generará los getters y setters para usted a menos que proporcione el código.

Esto significa que puede usar un campo "público" en Groovy y el compilador generará silenciosamente e invocará al setter/setter. Si necesita hacer magia adicional cuando se cambia un campo, puede presentar un colocador especializado y todo funcionará.

Es una de esas cosas donde la realidad choca con un diseño. Los diseñadores de Java no querían que el compilador hiciera nada que no pueda ver. Lo que parecía una buena idea hace muchos años, no resultó demasiado bien.

Answer 5

Me di cuenta de un uso útil de la propiedad. Si va a vincular la colección de su objeto a un DataGrid o DataGridView u otro control enlazable, los únicos nombres evaluables reconocibles son los campos Propiedad y no los campos públicos.