¿Por qué utilizar campos en lugar de propiedades?

Question

Soy bastante nuevo en C#, y creo que las propiedades son maravillosas. Tan maravilloso, de hecho, que no puedo ver ninguna ventaja real en el uso de campos, en cambio. Incluso para los campos privados, parece que la flexibilidad y la modularidad que ofrecen las propiedades pueden, en el mejor de los casos, ahorrarle dolores de cabeza graves y, en el peor de los casos, no tener ningún efecto.

La única ventaja que puedo ver para los campos es que puede inicializarlos en línea. Pero la mayoría de las veces, desea inicializarlos en el constructor, de todos modos. Si no está utilizando la inicialización en línea, ¿hay alguna razón para no usar propiedades todo el tiempo?

Editar: Algunas personas han mencionado la necesidad de hacer una copia de seguridad de las propiedades con los campos (de forma explícita o automática). Deje que aclare mi pregunta: ¿Hay alguna razón para usar los campos excepto para hacer una copia de seguridad de las propiedades? Es decir, ¿hay algún momento en que SomeType someField; sea preferible a SomeType SomeProperty { get; set; }?

Editar 2: DanM, Skurmedel y Seth dieron respuestas realmente útiles. Acepté el de DanM, ya que es el más completo, pero si alguien resumiera sus respuestas en una sola respuesta, estaría encantado de aceptarlo.

Answer 1

Normalmente, las propiedades necesitan un campo de respaldo a menos que sean simples "propiedades automáticas" de getter/setter.

Por lo tanto, si sólo está haciendo ...

public string Name { get; set; } // automatic property 

... que no es necesario un campo, y estoy de acuerdo, no hay razón para tener uno.

Sin embargo, si estás haciendo ...

public string Name 
{ 
    get { return _name; } 
    set 
    { 
     if (value = _name) return; 
     _name = value; 
     OnPropertyChange("Name"); 
    } 
} 

... necesita que _name campo de respaldo.

Para las variables privadas que no requieren ninguna lógica especial de obtención/configuración, es realmente una decisión de juicio si se debe hacer una propiedad automática privada o solo un campo. Usualmente hago un campo, luego, si necesito que sea protected o public, lo cambiaré a una propiedad automática.

actualización

Como se ha señalado por Yassir, si utiliza las propiedades automáticas, todavía hay un campo que está al acecho detrás de las escenas, simplemente no es algo que realmente tiene que escribir. Entonces, la conclusión es que las propiedades no almacenan datos, sino que proporcionan acceso a los datos. Los campos son los que realmente contienen los datos. Entonces, los necesitas aunque no puedas verlos.

Actualización 2

cuanto a su pregunta revisada ...

¿Hay algún momento que SomeType SomeField; es preferible a SomeType SomeProperty { get; set; }?

... una cosa que viene a la mente: Si usted tiene un campo privado, y (según la convención de campos privados) que llamarlo _name, que las señales a usted y cualquiera que lea el código que se está trabajando directamente con datos privados. Si, por otro lado, haces de todo una propiedad, y (de acuerdo con la convención de propiedades) llama a tu propiedad privada Name, ahora no puedes simplemente mirar la variable y decir que se trata de datos privados. Entonces, usar solo propiedades quita algo de información. No he intentado trabajar con todas las propiedades para evaluar si esa es información crucial, pero definitivamente algo se pierde.

Otra cosa, más leve, es que public string Name { get; set; } requiere más tipeo (y es un poco más desordenado) que private string _name.

Answer 2

Hay no motivo para exponer públicamente los campos.

Si pública expone un campo que no se puede cambiar la fuente de la información, desde el defination en línea en el archivo de configuración sin refactorización. \

Se puede usar un campo de ocultar datos internos. Raramente estoy a favor de eso, solo uso campos cuando estoy haciendo algo para ocultarlo públicamente y usarlo en una propiedad. (es decir, no estoy utilizando la generación automática de propiedades)

Answer 3

Los campos y las propiedades no son intercambiables. Supongo que lo que estás diciendo es acceder a campos privados a través de propiedades privadas. Hago esto cuando tiene sentido, pero en su mayor parte, no es necesario. El optimizador JIT tendrá acceso en línea a un campo privado a través de una propiedad privada en la mayoría de los casos de todos modos. Y envolver un campo privado en una propiedad privada no se considera un cambio radical ya que los miembros privados no son parte de su interfaz.

Personalmente, quisiera nunca exponer cualquier campo de instancia protegida/pública. Sin embargo, generalmente es aceptable exponer un campo público estático con un modificador de solo lectura, siempre que el tipo de campo sea inmutable. Esto se ve a menudo con los campos estáticos SomeStruct.Empty.

Answer 4

Las propiedades son una cosa maravillosa, pero hay gastos generales asociados con el acceso a la propiedad. No necesariamente es un problema, sino algo a tener en cuenta.

Evitar el uso excesivo de la Propiedad captadores y definidores

mayoría de las personas no se dan cuenta de que la propiedad getters y setters son similares a los métodos cuando se trata de gastos generales; es principalmente la sintaxis que los diferencia. El compilador incluirá un getter o setter de propiedad no virtual que no contenga instrucciones distintas al acceso de campo, pero en muchos otros casos esto no es posible. Debes considerar cuidadosamente tu uso de las propiedades; desde dentro de una clase, acceda directamente a los campos (si es posible) y nunca llame ciegamente a las propiedades repetidamente sin almacenar el valor en una variable. Dicho todo esto, ¡esto no significa que debas usar campos públicos!

Fuente: http://dotnet.sys-con.com/node/46342

Answer 5

Como otros han señalado, necesitará un campo privado para respaldo de las propiedades de todos modos.

También hay una ventaja de velocidad en el uso de campos sobre las propiedades. En el 99.99% de los casos no importará. Pero en algunos podría.

Answer 6

Los campos son el único lugar donde puede almacenar estado.Las propiedades son en realidad solo un par de métodos con sintaxis especial que les permite mapearse al método get o set, dependiendo de cómo se estén usando: si una propiedad modifica o accede al estado, ese estado todavía tiene que ser almacenado en un campo .

No siempre ve los campos. Con las propiedades automáticas C# 3, el compilador crea el campo para usted. Pero todavía está allí. Además, las propiedades automáticas tienen algunas limitaciones importantes (por ejemplo, sin soporte INotifyPropertyChanged, sin lógica comercial en los setters) que significan que a menudo son inapropiadas, y usted necesita crear un campo explícito y una propiedad definida manualmente de todos modos.

Según David's answer, tienes razón si hablas de una API: casi nunca deseas que el estado interno (campos) forme parte de la API.

Answer 7

Si quieres tener algo readonly tienes que usar un campo ya que no hay forma de decirle a una propiedad automática que genere un campo de solo lectura.

Lo hago con bastante frecuencia.

ejemplo Contrived:

class Rectangle 
{ 
    private readonly int _width; 
    private readonly int _height; 

    public Rectangle(int width, int height) 
    { 
     _width = width; 
     _height = height; 
    } 

    public int Width { get { return _width; } } 
    public int Height { get { return _height; } } 
} 

Esto significa nada dentro de rectángulo puede alterar la anchura o la altura después de la construcción. Si uno intenta, el compilador se quejará.

Si en lugar de eso hubiera usado una propiedad automática con un setter privado, el compilador no me protegería de mí mismo.

Otra razón que veo es, si un dato no tiene que estar expuesto (permanecer private) ¿por qué hacer una propiedad?

Answer 8

La sintaxis para los campos es mucho más rápida de escribir que para las propiedades, por lo que cuando es seguro usar un campo (privado para la clase) ¿por qué no usarlo y guardar esa escritura adicional? Si las propiedades implementadas automáticamente tuvieran la breve sintaxis concisa corta y tuvieras que hacer un trabajo extra para crear un campo viejo simple, las personas podrían comenzar a usar propiedades en su lugar. Además, es una convención ahora en C#. Así es como piensan las personas, y es lo que esperan ver en el código. Si haces algo diferente de lo normal, confundirás a todos.

Pero podría preguntar por qué la sintaxis de los campos no crea una propiedad implementada automáticamente en lugar de un campo, por lo que obtiene lo mejor de ambos mundos: propiedades en todas partes y una sintaxis concisa.

Hay una razón muy simple por lo que todavía tiene que tener campos explícitos:

C# 1.0 no tenía todas estas características agradables que tenemos ahora, por lo que los campos eran un hecho de la vida - realmente no se podía vive sin ellos Montones y montones de código dependen de que los campos y las propiedades sean cosas visiblemente diferentes. Simplemente no se puede cambiar ahora sin romper toneladas de código.

También sospecho que hay implicaciones de rendimiento, pero quizás eso se pueda resolver con el jitter.

Así que estamos atrapados con los campos para siempre, y ya que están ahí y han tomado la mejor sintaxis, tiene sentido usarlos cuando sea seguro hacerlo.

Answer 9

No veo por qué usarías autopropiedades privadas.¿Qué ventaja hay para

private int Count {get; set;} 

sobre

private int count 

Answer 10

Aunque estoy de acuerdo con lo que perciben como la "intención" en la declaración de David Basarab: "No hay ninguna razón para exponer públicamente campos," I' Me gustaría añadir un énfasis ligeramente diferente:

Modificaría la cita de David arriba para que diga: "No hay ninguna razón para exponer públicamente campos ... fuera de una clase ... excepto a través de la opción consciente de encapsular los campos en Propiedades a través de los cuales el acceso es rigurosamente contro llenó

propiedades no son simplemente una "chapa" de la sintaxis sobre los campos "añadidas a" C#: son una característica del lenguaje fundamental diseñada por buenas razones, entre ellas:

1. controlar lo que está expuesta y no expuesta clases externas (encapsulación, ocultación de datos)

2. permitiendo que se realicen ciertas acciones cuando se accede o establece una propiedad: acciones que se expresan mejor en el conjunto de propiedades 'get y', en lugar de ser 'elevadas' a definidas externamente métodos.

3. Las interfaces por diseño no pueden definir 'campos: pero pueden definir Propiedades.

buen diseño orientado a objetos significa tomar decisiones conscientes acerca de "estado":

1. campos variables locales: qué estado se encuentra privado a un método y transitorios: variables locales normalmente sólo válidos en el ámbito de un cuerpo de método, o incluso con una vida útil "tan estrecha" como dentro del alcance de algo así como un ciclo 'for'. Por supuesto, también puede considerar las variables de parámetro en un método como "local".

2. campos de instancia de clase: qué estado es privado para una clase, y tiene existencia independiente para cada instancia de una clase, pero es muy probable que se requiera su uso en varios lugares de la clase.

3. campos de instancias estáticas: qué estado será una propiedad de la clase solamente, independientemente del número de instancias de la clase.

4. estado expuesto deliberadamente y conscientemente "fuera" de la clase: la idea clave es que hay al menos un nivel de indirección interpuesto entre la clase y los "consumidores" de los datos que expone la clase. El "lado opuesto" de "exposición" es, por supuesto, la intención consciente de ocultar (encapsular, aislar) el código de implementación.

   a. a través de propiedades públicas: todos los aspectos de esto bien cubiertos en todas las otras respuestas aquí

   b. a través de los indexadores

   c. a través de los métodos

   d. las variables estáticas públicas se encuentran generalmente en clases de utilidad, que a menudo son clases estáticas.

sugerimos que revise: MSDN on 'Fields ... MSDN on Properties ... MSDN on Indexers

Answer 11

velocidad. Si un campo se establece o lee miles de millones de veces en el transcurso de una simulación, entonces desea utilizar un campo y no una propiedad para evitar la sobrecarga de una llamada secundaria. Conforme a OO (DDD?) Tanto como sea posible, en estos casos, recomendaría recurrir a los campos solo en la clase dedicada a representar a algún tipo de persona de "valor". La lógica debe mantenerse al mínimo. Más bien, tenga un creador personal o un asesor personal.

Pero si tiene estos problemas, entonces probablemente no esté programando C++ y no C#, ¿verdad?

Answer 12

Sólo trate utilizando una propiedad cuando se utiliza árbitro de entrada/salida args:

someObject.SomeMethod(ref otherObject.SomeProperty); 

No va a compilar.

Answer 13

Hay varias respuestas buenas (parciales) de @Seth (los campos tienen un mejor rendimiento, por lo que en un contexto privado puede ser útil en su beneficio cuando tiene sentido), @Skurmedel (los campos pueden ser de solo lectura), @ Jenk (los campos se pueden usar para ref/out). Pero me gustaría agregar uno más:

Puede usar la sintaxis de inicialización optimizada para establecer el valor de un campo, pero no una propiedad. es decir:

private int x = 7; 

vs

private int x { get; set; } 

// This must go in the constructor, sometimes forcing you to create 
// a constructor that has no other purpose. 
x = 7;