¿Por qué tener propiedades de conjunto vacío en lugar de usar una variable miembro pública?

Question

Duplicar posible:
C#: Public Fields versus Automatic Properties

duplicado? Creo que no:
Esta pregunta es no lo mismo que "¿Por propiedades de uso en lugar de ámbito público ". Una propiedad con un getter y setter especificado es muy diferente que un campo público. Mi pregunta era, es una propiedad SIN un getter y setter, cualquiera diferente.

Con la capacidad algo reciente de tener getters y setters vacíos, ¿cuál es el beneficio de usarlos en lugar de simplemente declarar una variable miembro pública?

Ejemplo:

public string MyProperty 
{ 
    get; 
    set; 
} 

frente:

public string MyProperty; 

Answer 1

Una palabra: herencia.

Las propiedades son heredables mientras que los campos no son heredables. Puede usar campos en una clase heredada, pero no alterar su comportamiento haciéndolos virtuales.

así:

public class Foo { 
    public virtual int MyField = 1; // Nope, this can't 

    public virtual int Bar {get; set; } 
} 

public class MyDerive : Foo { 
    public override MyField; // Nope, this can't 

    public override int Bar { 
    get { 
     //do something; 
    } 
    set; } 
} 

Editar: Además del hecho de la herencia, los puntos se señala en las otras respuestas (como la visibilidad) son también un gran beneficio de las propiedades más campos.

Answer 2

Una cosa que puede hacer con propiedades que no se puede hacer con los campos es la visibilidad límite, ya sea para incubadora o captador:

public string MyProperty { get; private set; } 

algo que utilizo mucho.

Y algo (más poderoso) que no se puede hacer con los campos es definirlos dentro de una interfaz. Supongamos que desea una interfaz que requiere la implementación de clases para tener una cierta propiedad:

public interface MyInterface 
{ 
    string MyProperty { get; } 
} 

Tenga en cuenta que usted no necesita tener un colocador aquí. Depende exclusivamente de la implementación de las clases determinar cómo deben establecer MyProperty.

Answer 3

Los campos no se pueden exponer en las interfaces. Y la propiedad automática se puede cambiar a una propiedad "normal" en cualquier momento si es necesario, sin tener que cambiar la firma y la interfaz de la clase.

En general, los campos se consideran un detalle de implementación, que puede cambiar en futuras versiones del código. Por lo tanto, debe exponer los datos a través de métodos y propiedades, dejando el camino abierto para cambios internos en el futuro que no afecten el código que usa la clase.

Answer 4

La idea es administrar los valores dentro del objeto, estado, evitando la corrupción y el uso indebido mediante el código de llamada.

Answer 5

Una propiedad le da varias ventajas sobre un simple ámbito público:

• puede controlar si la propiedad es de sólo lectura, sólo escritura o lectura/escritura
• puede ocultar la implementación real (tal vez en la incubadora que quiere hacer algo más que el establecimiento de un valor)
• cuando se utiliza el enlace de datos (por ejemplo, en ASP.NET), tendrá que utilizar las propiedades (no funciona con campos)

Answer 6

Y Puede marcar propiedades con atributos que no están disponibles en los miembros. Hay atributos que solo se aplican a campos en el espacio de nombres de DataContract que afecta la serialización, el atributo no se puede aplicar a campos, etc.

Es cierto que no hay nada técnicamente que impida que estos atributos se usen en miembros, pero sin embargo, solo trabajan en propiedades.

Answer 7

El acoplamiento apretado viene a la mente. El uso de campos públicos elimina la capa de abstracción disponible mediante el uso de propiedades. El uso de campos y propiedades privadas oculta la implementación de otras clases y ayuda a aislarlas (clases externas) cada vez que sea necesario un cambio.

Además, tenga en cuenta que se refiere al auto-implemented properties que hace que el compilador cree el campo de respaldo para usted en lugar de tener que crear manualmente el campo de respaldo (privado) para cada propiedad en su clase.