Propiedades automáticas C # 3.0: ¿útiles o no? [cerrado]

Nota: Esto se publicó cuando comenzaba C #. Con el conocimiento de 2014, realmente puedo decir que las propiedades automáticas 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 un campo público:

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

Ahora, con .NET 3.0, tenemos 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 por 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 fanático 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 quiero implementar algo de lógica getter / setter, tengo que usar el par privado / público de todos modos.

Veo el beneficio de que guardo mucho código (uno frente a seis líneas) sin perder la capacidad de cambiar la lógica del captador / definidor más tarde, pero de nuevo ya puedo hacerlo simplemente declarando un campo público "Título de cadena pública" sin la necesidad de {get; conjunto; } bloque, por lo tanto, incluso guardando más código.

Entonces, ¿qué me estoy perdiendo aquí? ¿Por qué alguien querría usar propiedades automáticas?

Los usamos todo el tiempo en Stack Overflow.

También puede estar interesado en una discusión de Propiedades vs. Variables públicas . En mi humilde opinión, eso es realmente una reacción, y para ese propósito, es genial.

Sí, solo guarda el código. Es mucho más fácil de leer cuando tienes un montón de ellos. 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 setter privado a través de la reflexión.

A partir de C # 6 también puede crear readonlypropiedades 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 se convertirá en:

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

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

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

Las tres grandes desventajas de usar campos en lugar de propiedades son:

1. No puede enlazar datos a un campo mientras que puede a una propiedad
2. Si comienza a usar un campo, no podrá cambiarlo (fácilmente) más tarde a una propiedad
3. Hay algunos atributos que puede agregar a una propiedad que no puede agregar a un campo

Personalmente me encantan las propiedades automáticas. ¿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 en propiedades normales más adelante.

Como dijiste, podrías usar campos, y si quisieras agregarles lógica más tarde, los convertirías en propiedades. Pero esto podría presentar problemas con cualquier uso de la reflexión (y posiblemente en otros lugares).

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

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

De Bjarne Stroustrup, creador de C ++:

Particularmente no me gustan las clases con muchas funciones get y set. 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.

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

Una cosa que nadie parece haber mencionado es cómo las propiedades automáticas desafortunadamente no son útiles para objetos inmutables (generalmente estructuras inmutables). Porque para eso realmente 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).

Esto tiene ventajas sobre una propiedad simple get/ private setautomática.

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

Las propiedades automáticas son tan mágicas como cualquier otra cosa en C #. Una vez que lo piensa en términos de compilar a IL en lugar de expandirlo a una propiedad normal de C # primero, es mucho menos magia negra que muchas otras construcciones de lenguaje.

Yo uso propiedades automáticas 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";

Debe cambiar los valores predeterminados a sus constructores con propiedades. tedioso :-(

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

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 pusieron los dos juntos está más allá de mí. Un simple "parcial en <PropertyName> cambiado" habría hecho que estas cosas fueran realmente muy útiles.

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

Tan sencillo como eso.

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

En mi opinión, siempre debes usar las propiedades automáticas en lugar de los campos públicos. Dicho esto, aquí hay un compromiso:

Comience con un campo interno utilizando la convención de nomenclatura que usaría para una propiedad. Cuando tú tampoco

• necesita acceso al campo desde fuera de su ensamblaje, o
• necesita adjuntar lógica a un captador / definidor

Hacer esto:

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

Su código de cliente no tendrá que cambiar.

Sin embargo, algún día su sistema crecerá y lo descompondrá en ensamblajes separados y múltiples soluciones. Cuando eso suceda, los campos expuestos volverán a atormentarte porque, como Jeff mencionó, cambiar un campo público a una propiedad pública es un cambio de API de última hora .

Yo 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.

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

@Domenic: No lo entiendo ... ¿no puedes hacer esto con las propiedades automáticas ?:

public string Title { get; }

o

public string Title { get; private set; }

¿A esto te refieres?

Mi mayor queja con las propiedades automáticas es que están diseñadas para ahorrar tiempo, pero a menudo encuentro que más tarde tengo que expandirlas a propiedades completas.

Lo que falta a VS2008 es un refactor de Autodestrucción de propiedad .

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