c# - studio - ¿Por qué tener vacías las propiedades del conjunto en lugar de usar una variable miembro pública?

que es set en programacion

Question

Posible duplicado:
C #: Campos públicos versus propiedades automáticas

¿Duplicar? Yo creo que no:
Esta pregunta no es lo mismo que "Por qué usar propiedades en lugar de campo público". Una propiedad con un getter y setter especificado es muy diferente a un campo público. Mi pregunta era, es una propiedad SIN un getter y setter, 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;
}

versus:

public string MyProperty;

Answer 1

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 privados oculta la implementación de otras clases y ayuda a aislarlas (clases externas) siempre que sea necesario un cambio.

Además, tenga en cuenta que se refiere a las propiedades implementadas automáticamente que hacen que el compilador cree el campo de respaldo en lugar de que usted tenga que crear manualmente el campo de respaldo (privado) para cada propiedad de su clase.

Answer 2

La idea es administrar los valores dentro del objeto, estado, evitando la corrupción y el mal uso al llamar al código.

Answer 3

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

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 al código que utiliza la clase.

Answer 4

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

Es cierto que no hay nada que evite técnicamente que estos atributos se utilicen en los miembros, pero, sin embargo, solo funcionan en las propiedades.

Answer 5

Una cosa que puede hacer con las propiedades que no puede hacer con los campos es limitar la visibilidad para el establecedor o el que obtiene:

public string MyProperty { get; private set; }

Algo que uso bastante.

Y algo (más poderoso) que no puedes hacer con los campos es definirlos dentro de una interfaz. Supongamos que desea una interfaz que requiere que las clases de implementación tengan una propiedad determinada:

public interface MyInterface
{
string MyProperty { get; }
}

Tenga en cuenta que no necesita tener un setter aquí. MyProperty completamente de la implementación de clases determinar cómo deben configurar MyProperty .

Answer 6

Una palabra: herencia.

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

Al igual que:

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; }
}

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

Answer 7

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

• puede controlar si la propiedad es de solo lectura, de solo escritura o de lectura / escritura
• puede ocultar la implementación real (tal vez en el setter desea hacer más que solo establecer un valor)
• cuando use el enlace de datos (por ejemplo, en ASP.NET), tendrá que usar propiedades (no funciona con campos)