programacion - propiedades en c#

Propiedades automáticas de C#3.0: ¿útiles o no?

Question

Nota: Esto fue publicado cuando comencé C #. Con el conocimiento de 2014, puedo decir que las propiedades automotrices se encuentran entre las mejores cosas que le han pasado al lenguaje C #.

Estoy acostumbrado a crear mis propiedades en C # usando un campo privado y público:

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Ahora, con .NET 3.0, obtuvimos propiedades automáticas:

public string Title { get; set; }

Sé que esto es más una pregunta filosófica / subjetiva, pero ¿hay alguna razón para usar estas propiedades automáticas, excepto guardar cinco líneas de código para cada campo? Mi queja personal es que esas propiedades me ocultan cosas, y no soy un gran admirador de la magia negra.

De hecho, el campo privado oculto ni siquiera aparece en el depurador, lo cual está bien dado el hecho de que las funciones get / set no hacen nada. Pero cuando realmente quiero implementar alguna lógica getter / setter, tengo que usar el par privado / público de todos modos.

Veo el beneficio de que guardo un montón de código (uno frente a seis líneas) sin perder la capacidad de cambiar la lógica getter / setter más tarde, pero de nuevo ya puedo hacerlo simplemente declarando un campo público "Public string Title" sin la necesidad de {get; conjunto; } bloquear, incluso guardando más código.

Entonces, ¿qué me estoy perdiendo aquí? ¿Por qué alguien realmente querría usar auto-propiedades?

Answer 1

@Domenic: no lo entiendo ... ¿no puedes hacer esto con auto-propiedades ?:

public string Title { get; }

o

public string Title { get; private set; }

¿A esto te refieres?

Answer 2

Bueno, con los fragmentos de código una propiedad automática del mismo nombre sería de siete teclas en total;)

Answer 3

Creo que cualquier construcción que sea intuitiva Y reduzca las líneas de código es una gran ventaja.

Ese tipo de características es lo que hace que los lenguajes como Ruby sean tan potentes (eso y características dinámicas, que también ayudan a reducir el exceso de código).

Ruby ha tenido esto todo el tiempo como:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Answer 4

De Bjarne Stroustrup, creador de C ++:

En particular, no me gustan las clases con muchas funciones de obtención y configuración. Eso es a menudo una indicación de que no debería haber sido una clase en primer lugar. Es solo una estructura de datos. Y si realmente es una estructura de datos, conviértala en una estructura de datos.

¿Sabes qué? El tiene razón. ¿Con qué frecuencia está simplemente envolviendo campos privados en un get y set, sin realmente hacer nada dentro del get / set, simplemente porque es lo "orientado a objetos" que hacer? Esta es la solución de Microsoft al problema; son básicamente campos públicos a los que puedes vincular.

Answer 5

El único problema que tengo con ellos es que no van lo suficientemente lejos. La misma versión del compilador que agregó propiedades automáticas, agregó métodos parciales. Por qué no juntaron los dos está más allá de mí. Un simple "parcial On <PropertyName> Changed" hubiera hecho estas cosas realmente útiles.

Answer 6

En mi opinión, siempre debes usar auto-propiedades en lugar de campos públicos. Dicho eso, aquí hay un compromiso:

Comience con un campo internal utilizando la convención de nomenclatura que usaría para una propiedad. Cuando primero o

• necesita acceso al campo desde fuera de su ensamblado, o
• necesidad de adjuntar lógica a un getter / setter

Hacer esto:

1. renombrar el campo
2. hazlo privado
3. agregar una propiedad pública

Su código de cliente no necesitará cambiar.

Algún día, sin embargo, su sistema crecerá y lo descompondrá en conjuntos separados y múltiples soluciones. Cuando eso suceda, cualquier campo expuesto volverá a perseguirte porque, como lo mencionó Jeff, cambiar un campo público a una propiedad pública es un cambio abrupto en la API .

Answer 7

Es simple, es corto y si desea crear una implementación real dentro del cuerpo de la propiedad en algún momento, no romperá la interfaz externa de su tipo.

Tan sencillo como eso.

Answer 8

Las propiedades automáticas son tanto una magia negra como cualquier otra cosa en C #. Una vez que lo piensas en términos de compilar hasta IL en lugar de expandirse a una propiedad normal de C #, es mucho menos magia negra que muchos otros constructos de lenguaje.

Answer 9

Las tres desventajas principales del uso de campos en lugar de propiedades son:

1. No puedes enlazar datos a un campo mientras que puedes a una propiedad
2. Si comienzas usando un campo, no podrás cambiarlos (fácilmente) a una propiedad
3. Hay algunos atributos que puede agregar a una propiedad que no puede agregar a un campo

Answer 10

Los usamos todo el tiempo en .

Usted también podría estar interesado en una discusión de Propiedades vs. Variables Públicas . En mi humilde opinión, eso es realmente a lo que es una reacción, y para eso, es genial.

Answer 11

Mi mayor queja con las propiedades automotrices es que están diseñadas para ahorrar tiempo, pero a menudo me veo en la necesidad de expandirlas a propiedades completas.

Lo que falta en el VS2008 es un refactor de Propiedad de Autodestrucción.

El hecho de que tengamos un refactor de campo encapsulado hace que la forma en que trabajo sea más rápida para simplemente usar campos públicos.

Answer 12

Personalmente, me encantan las propiedades automotrices. ¿Qué hay de malo en guardar las líneas de código? Si desea hacer cosas en getters o setters, no hay problema para convertirlas a propiedades normales más adelante.

Como dijiste, podrías usar campos, y si quisieras agregarles lógica, los convertirías en propiedades. Pero esto podría presentar problemas con cualquier uso de la reflexión (¿y posiblemente en otro lugar?).

Además, las propiedades le permiten establecer diferentes niveles de acceso para el getter y el setter que no puede hacer con un campo.

Supongo que es lo mismo que la palabra clave var. Una cuestión de preferencia personal.

Answer 13

Sí, solo guarda código. Son millas más fáciles de leer cuando tienes muchas. Son más rápidos de escribir y más fáciles de mantener. Guardar código siempre es un buen objetivo.

Puede establecer diferentes ámbitos:

public string PropertyName { get; private set; }

Para que la propiedad solo se pueda cambiar dentro de la clase. Esto no es realmente inmutable, ya que aún puede acceder al establecimiento privado a través de la reflexión.

A partir de C # 6, también puede crear propiedades de readonly verdaderas, es decir, propiedades inmutables que no se pueden cambiar fuera del constructor:

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

En tiempo de compilación que se convertirá en:

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

En las clases inmutables con muchos miembros, esto ahorra mucho código en exceso.

Answer 14

Siempre creo propiedades en lugar de campos públicos porque puede usar propiedades en una definición de interfaz, no puede usar campos públicos en una definición de interfaz.

Answer 15

Una cosa a tener en cuenta aquí es que, a mi entender, esto es solo azúcar sintáctica en el extremo C # 3.0, lo que significa que el IL generado por el compilador es el mismo. Estoy de acuerdo en evitar la magia negra, pero de todos modos, menos líneas para la misma cosa suele ser algo bueno.

Answer 16

Una cosa que nadie parece haber mencionado es que desafortunadamente las auto-propiedades no son útiles para objetos inmutables (generalmente estructuras inmutables). Porque para eso deberías hacer:

private readonly string title;
public string Title
{
    get { return this.title; }
}

(donde el campo se inicializa en el constructor a través de un parámetro pasado, y luego es de solo lectura).

Así que esto tiene ventajas sobre una simple propiedad automática get / private set .

Answer 17

Uso CodeRush, es más rápido que las propiedades automáticas.

Para hacer esto:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Requiere ocho pulsaciones de teclas en total.

Answer 18

Uso auto-propiedades todo el tiempo. Antes de C # 3 no podía molestarme con todo el tipeo y solo usaba variables públicas.

Lo único que extraño es poder hacer esto:

public string Name = "DefaultName";

Tienes que cambiar los valores predeterminados en tus constructores con propiedades. tedioso :-(