C# 3.0 auto-propiedades — útil o no?[cerrado]

Question

Nota:Esto fue publicado cuando yo estaba empezando en C#.Con conocimiento de 2014, puedo decir con verdad que el auto-propiedades están entre las mejores cosas que le ha pasado a la del lenguaje C#.

Estoy acostumbrado a crear mis propiedades en C# usando una privada y una pública de campo:

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

Ahora, con .NET 3.0, tenemos auto-propiedades:

public string Title { get; set; }

Sé que esto es más filosófico/preguntas subjetivas, pero ¿hay alguna razón para utilizar estos auto-propiedades, excepto de ahorro de cinco líneas de código para cada campo?Personal de mi queja es que esas propiedades están ocultando cosas de mí, y yo no soy un gran fan de la magia negra.

De hecho, la escondida campo privado no aparecen en el depurador, que está bien, dado el hecho de que el get/set funciones no hacer nada.Pero cuando quiero poner en práctica algunas de captador/definidor de la lógica, tengo que usar el privado/público par de todos modos.

Veo el beneficio que puedo ahorrar un montón de código (uno vs seis líneas), sin perder la capacidad de cambiar el getter/setter lógica más tarde, pero de nuevo, que puedo hacer ya que simplemente declarar un campo público "Public string Título" sin la necesidad de la { get;conjunto;} bloque, de ahí que incluso el ahorro de más de código.

Así que, ¿qué me estoy perdiendo aquí?¿Por qué alguien realmente desea utilizar auto-propiedades?

Answer 1

Las usamos todo el tiempo de Desbordamiento de Pila.

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

Answer 2

Sí, sí sólo guardar el código.Es millas más fácil de leer cuando usted tiene un montón de ellos.Son más rápidos para escribir y más fácil de mantener.Ahorro de código siempre es una buena meta.

Se pueden establecer diferentes ámbitos:

public string PropertyName { get; private set; }

De manera que la propiedad sólo puede ser cambiado dentro de la clase.Esta realidad no es inmutable como usted todavía puede tener acceso a la privada setter a través de la reflexión.

Como de C#6 también puede crear cierto readonly propiedades - es decir,inmutable propiedades que no se puede cambiar fuera de el 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 inmutable clases con una gran cantidad de miembros que esto ahorra una gran cantidad de exceso de código.

Answer 3

Los tres grandes desventajas para el uso de los campos en lugar de las propiedades son:

1. Usted no puede enlazar a un campo mientras que usted puede a una propiedad
2. Si usted comienza con un campo, no se puede más tarde (fácilmente) cambiar a una propiedad
3. Hay algunos atributos que se pueden agregar a una propiedad que no se puede agregar a un campo

Answer 4

A mi personalmente me encanta auto-propiedades.Lo que está mal con el ahorro de las líneas de código?Si quieres hacer cosas en captadores o incubadoras, no hay ningún problema para convertir a la normal de las propiedades más tarde.

Como usted dijo que usted podría utilizar campos, y si quería añadir lógica a ellos más tarde se había de convertir a propiedades.Pero esto puede presentar problemas con el uso de la reflexión (y posiblemente en otros lugares?).

También las propiedades que le permiten establecer diferentes niveles de acceso para los getter y setter que no se puede hacer con un campo.

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

Answer 5

De Bjarne Stroustrup, creador de C++:

Particularmente me desagradan las clases, con un montón de get y set de funciones.Que es a menudo una indicación de que no debe haber sido una clase en el primer lugar.Es sólo una estructura de datos.Y si realmente es una estructura de datos, hacer una estructura de datos.

¿Y saben qué?Él está en lo correcto.¿Con qué frecuencia usted simplemente envolver campos privados en un get y set, sin realmente hacer nada dentro de la get/set, simplemente porque es el "orientada a objeto" de hacer las cosas.Este es Microsoft la solución al problema;básicamente son campos públicos que se pueden vincular.

Answer 6

Una cosa que parece que nadie ha mencionado es cómo auto-propiedades son, lamentablemente, no es útil para objetos inmutables (generalmente inmutable structs).Porque para que usted realmente debe 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 pasado parámetro y, a continuación, es de sólo lectura.)

Así que esto tiene ventajas sobre un simple get/private set autoproperty.

Answer 7

Yo siempre crear propiedades en lugar de campos públicos porque usted puede usar las propiedades en una definición de interfaz, usted no puede utilizar los campos públicos en una definición de interfaz.

Answer 8

Auto-propiedades tanto en la magia negra, como cualquier otra cosa en C#.Una vez que usted piensa en él en términos de elaboración de abajo a la IL en lugar de ser ampliado a un normal C# propiedad de la primera es mucho menos magia negra que un montón de otras construcciones del lenguaje.

Answer 9

Yo uso auto-propiedades de todo el tiempo.Antes de C#3 yo no podía ser molestado con todas las de escribir y sólo utiliza las variables públicas en su lugar.

La única cosa que echo de menos es ser capaz de hacer esto:

public string Name = "DefaultName";

Usted tiene que cambiar los valores predeterminados en su constructores con propiedades.tedioso :-(

Answer 10

Creo que cualquier construcción que es intuitivo Y reduce las líneas de código es un gran plus.

Los tipos de características es lo que hace que lenguajes como Ruby tan poderoso (que y características dinámicas, que también ayuda a reducir el exceso de código).

Ruby ha tenido todo esto, como:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Answer 11

El único problema que tengo con ellos es que ellos no van lo suficientemente lejos.La misma versión del compilador que añade propiedades automáticas, agregó métodos parciales.Por qué no poner los dos juntos es más allá de mí.Un simple "parcial En<PropertyName>Cambiado" tendría que haber hecho estas cosas realmente útiles.

Answer 12

Es simple, es corta y si desea crear una aplicación real dentro de la propiedad del cuerpo en algún lugar abajo de la línea, no va a romper su tipo de la interfaz externa.

Tan simple como eso.

Answer 13

Una cosa a tener en cuenta aquí es que, a mi entender, esta es sólo azúcar sintáctico en el C# 3.0 final, lo que significa que la IL generado por el compilador es el mismo.Estoy de acuerdo acerca de evitar que la magia negra, pero al mismo tiempo, un número de líneas de la misma cosa, es generalmente una buena cosa.

Answer 14

En mi opinión, siempre se debe utilizar la auto-propiedades en lugar de campos públicos.Eso dicho, aquí es una solución de compromiso:

Comienza con un interna campo con la convención de nomenclatura que se utiliza para una propiedad.Cuando usted primero

• necesidad de acceso al campo desde fuera de su asamblea, o
• es necesario conectar la lógica a un getter/setter

Hacer esto:

1. cambiar el nombre del campo
2. hacer privado
3. agregar una propiedad pública

Su código de cliente no tenga que cambiar.

Algún día, sin embargo, el sistema va a crecer y se va a descomponer en asambleas separadas y múltiples soluciones.Cuando eso sucede, alguna exposición de los campos se vuelven en tu contra porque, como Jeff ha mencionado, el cambio de una esfera pública para un público de la propiedad se convierte en un cambio de API.

Answer 15

Yo uso CodeRush, es más rápido que el auto-propiedades.

Para hacer esto:

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

Se requiere ocho pulsaciones de teclas en total.

Answer 16

Bien con fragmentos de código auto-propiedad con el mismo nombre, habría siete pulsaciones de teclas en total ;)

Answer 17

@Domenic :No lo entiendo..no se puede hacer esto con auto-propiedades?:

public string Title { get; }

o

public string Title { get; private set; }

Es esto lo que usted se refiere?

Answer 18

Mi mayor queja con auto-propiedades es que están diseñadas para ahorrar tiempo, pero a menudo me encuentro que tengo que ampliar en plenas propiedades más tarde.

Lo VS2008 que falta es un Explotar Auto-Propiedad refactorizar.

El hecho de que contamos con un encapsular campo refactorizar hace que la manera de trabajar más rápido utilizar campos públicos.