Propiedades vs. Campos: Necesito ayuda para comprender los usos de las propiedades en los campos

Question

En primer lugar, he leído una lista de publicaciones sobre este tema y no creo haber captado las propiedades debido a lo que había llegado a comprender sobre encapsulamiento y modificadores de campo (privado, público ... ver).

Uno de los principales aspectos de C# que he aprendido es la importancia de la protección de datos dentro de su código mediante el uso de encapsulación. Pensé que lo entendía por la capacidad del uso de los modificadores (privado, público, interno, protegido). Sin embargo, después de conocer las propiedades, estoy algo desgarrado al comprender no solo las propiedades, sino también la importancia/capacidad general de la protección de datos (lo que entendí como encapsulación) dentro de C#.

Para ser más específicos, todo lo que he leído cuando llegué a las propiedades en C# es que usted debe tratar de utilizarlos en lugar de campos cuando se puede debido a:

1) que le permitirá cambie el tipo de datos cuando no pueda cuando acceda directamente al campo directamente.

2) Añaden un nivel de protección de acceso a datos

Sin embargo, por lo que 'pensé' yo había llegado a saber sobre el uso de modificadores de campo hizo # 2, me parecía que las propiedades acaba de generar código adicional a menos que tenga alguna razón para cambiar el tipo (# 1) - porque está (más o menos) creando métodos ocultos para acceder a los campos en lugar de directamente.

Luego están los modificadores completos que se pueden agregar a Propiedades, lo que complica aún más mi comprensión de la necesidad de propiedades para acceder a los datos.

He leído varios capítulos de diferentes escritores sobre "propiedades" y ninguno ha explicado realmente una buena comprensión de las propiedades frente a los campos frente a la encapsulación (y buenos métodos de programación).

¿Puede alguien explicar:

1) razón por la que me gustaría utilizar las propiedades en lugar de campos (especialmente cuando aparece sólo estoy agregando código adicional

2) algún consejo sobre reconocer el uso de propiedades y no verlas como simples métodos (con la excepción de que el conjunto get sea aparente) al rastrear el código de otras personas?

3) ¿Alguna regla general acerca de cuándo usar buenos métodos de programación?

Gracias y disculpas por la larga publicación: no quería hacer una pregunta que se me ha formulado 100 veces sin explicar por qué la vuelvo a formular.

Answer 1

No debe preocuparse por el código adicional necesario para acceder a los campos a través de propiedades, será "optimizado" por el compilador JIT (al subrayar el código). Excepto cuando es demasiado grande para ser alineado, pero de todos modos necesitabas el código adicional.

Y el código extra para definir propiedades simples es también mínima:

public int MyProp { get; set; } // use auto generated field. 

Cuando necesite modifique para requisitos particulares se pueden definir todos los días su propio campo después.

Así que le queda la capa adicional de encapsulación/protección de datos, y eso es algo bueno.

Mi regla: exponga campos siempre a través de propiedades

Answer 2

Las propiedades son la forma preferida para cubrir los campos para hacer cumplir la encapsulación. Sin embargo, son funcionales porque puedes exponer una propiedad que es de un tipo diferente y organizar el casting; puedes cambiar los modificadores de acceso; se usan en el enlace de datos WinForms; le permiten incrustar lógica ligera por propiedad, como notificaciones de cambio; etc.

Al mirar el código de otras personas, las propiedades tienen diferentes iconos de intellisense para los métodos.

Si cree que las propiedades son solo un código adicional, me gustaría pegarme con ellas de todos modos pero hacer su vida más fácil generando automáticamente la propiedad desde el campo (haga clic derecho -> Refactorizar -> Encapsular campo ...)

Answer 3

Hay muchos escenarios en los que utilizan un campo simple no causaría daños, pero
una propiedad se puede cambiar más fácilmente más tarde, es decir, si desea agregar un evento cada vez que cambia el valor o desea realizar algún valor/verificación de rango

Además, si tiene varios proyectos que dependen el uno del otro, tiene que volver a compilar todo lo que dependa de aquel en el que un campo se cambió a una propiedad.

Answer 4

why I would want to use properties instead of fields (especially when it appears I am just adding additional code

que desea utilizar las propiedades sobre los campos becuase, cuando se utiliza propiedades que se pueden utilizar los eventos con ellos, por lo que en un caso en el que desea hacer alguna acción cuando una propiedad cambia, puede enlazar algunos manipuladores a eventos PropertyChanging o PropertyChanged. En el caso de los campos esto no es posible. Los campos pueden ser públicos o privados o protegidos, en el caso de los accesorios, puede hacerlos de solo lectura, pero de forma privada.

any tips on recognizing the use of properties and not seeing them as simply methods (with the exception of the get;set being apparent) when tracing other peoples code?

Un método debería utilizarse cuando se espera que el valor de retorno a ser dinámico cada vez que llame, una propiedad debe ser utilizada cuando el valor de retorno no es tan enormemente dinámico.

Any general rules of thumb when it comes to good programming methods in relation to when to use what?

Sí, recomiendo encarecidamente la lectura de Framework Design guidelines para las mejores prácticas de una buena programación.

Answer 5

1) por la que se desea utilizar las propiedades en lugar de campos (especialmente cuando se aparece sólo estoy agregando código adicional

Siempre debe utilizar las propiedades siempre que sea posible. Ellos acceso directo abstracta al campo (que se crea para ti si no creas uno).Incluso si la propiedad no hace nada más que establecer un valor, puede protegerte más adelante. Cambiar un campo a una propiedad más adelante es un cambio radical, por lo que si tiene un campo público y desea cambiarlo a una propiedad pública, debe volver a compilar todo el código que originalmente accedió a ese campo.

2) cualquier consejos para reconocer el uso de propiedades y no verlos como simplemente métodos (con la excepción de la get; set siendo aparente) cuando rastreo de código de otros pueblos?

No estoy totalmente seguro de lo que está preguntando, pero al rastrear el código de otra persona, siempre debe asumir que la propiedad está haciendo algo más que obtener y establecer un valor. Si bien es una práctica aceptada no colocar grandes cantidades de código en getters y setter, no se puede simplemente asumir que, dado que es una propiedad, se comportará rápidamente.

3) Cualquier reglas generales cuando se trata de buenos métodos de programación en relación a cuándo utilizar qué?

Siempre utilizo las propiedades para obtener y establecer métodos donde sea posible. De esa forma puedo agregar código más adelante si necesito verificar que el valor esté dentro de ciertos límites, no nulo, etc. Sin usar propiedades, tengo que regresar y poner esas verificaciones en cada lugar al que acceda directamente al campo.

Answer 6

Las propiedades le permiten hacer otras cosas además de establecer u obtener un valor cuando las usa. En particular, te permiten hacer una lógica de validación.

Una mejor práctica es hacer que cualquier cosa que se exponga al público sea una propiedad. De esta forma, si cambia la lógica set/get más adelante, solo tiene que volver a compilar su clase, no todas las clases vinculadas a ella.

Answer 7

1) Hay varias razones por las que es posible que desee utilizar las propiedades más campos, aquí son sólo un par:

a) Al tener la siguiente

public string MyProperty { get; private set; } 

que está tomando la propiedad "leen solamente". Nadie que use su código puede modificar su valor. Hay casos en que esto no es estrictamente cierto (si su propiedad es una lista), pero estos son conocidos y tienen soluciones.

b) Si decide que necesita para aumentar la seguridad de sus propiedades de uso de código:

public string MyProperty 
{ 
    get { return _myField; } 
    set 
    { 
     if (!string.IsNullOrEmpty(value)) 
     { 
      _myField = value; 
     } 
    } 
} 

2) Se puede decir que estamos propiedades porque no tienen (). El compilador le dirá si intenta agregar corchetes.

3) Se considera buena práctica usar siempre propiedades.

Answer 8

Una de las cosas buenas de Properties es que el getter y el setter pueden tener diferentes niveles de acceso. Considere esto:

public class MyClass { 

    public string MyString { get; private set; } 

    //...other code 
} 

Esta propiedad solo se puede cambiar desde dentro, por ejemplo, en un constructor. Lea sobre Dependency Injection. La inyección de constructores y la inyección de propiedades se refieren a las propiedades de configuración desde algún tipo de configuración externa. Hay muchos marcos por ahí.Si profundiza en algunos de estos obtendrá una buena idea de las propiedades y su uso. La inyección de dependencia también lo ayudará con su tercera pregunta sobre buenas prácticas.

Al mirar el código de otras personas, puede decir si algo es un método o una propiedad porque sus iconos son diferentes. Además, en Intellisence, la primera parte del resumen de una propiedad es la palabra Propiedad.

Answer 9

Iba a decir que las propiedades (setters) son un gran lugar para generar eventos como NotifyPropertyChanged, pero alguien más me venció.

Otra buena razón para considerar Propiedades: digamos que usted usa una fábrica para construir algún objeto que tenga un constructor predeterminado, y usted prepara el objeto a través de sus Propiedades.

new foo() {Prop1 = "bar", Prop2 = 33, ...};

Pero si los usuarios externos actualizan su objeto, tal vez haya algunas propiedades que desee que vean como de solo lectura y no puedan establecerse (solo la fábrica debería poder configurarlas). Puede hacer que los ajustadores sean internos; esto solo funciona, por supuesto, si la clase del objeto está en el mismo ensamblaje que la fábrica.

Hay otras maneras de lograr este objetivo, pero utilizando Propiedades y visibilidad variable de acceso es una buena idea tener en cuenta si está haciendo el desarrollo basado en la interfaz, o si se expone a bibliotecas de otros, etc.

Answer 10

Mientras No me gusta exponer directamente los campos al público, hay otra cosa: los campos no se pueden exponer a través de las interfaces; Las propiedades pueden.

Answer 11

Una advertencia es que cosas como "Threading.Interlocked.Increment" pueden funcionar con campos, pero no pueden trabajar con propiedades. Si dos hilos llaman simultáneamente a Threading.Interlocked.Increment en SomeObject.LongIntegerField, el valor aumentará en dos, incluso si no hay otro bloqueo. Por el contrario, si dos hilos invocan simultáneamente Threading.Interlocked.Increment en SomeObject.LongIntegerProperty, el valor de esa propiedad puede aumentarse en dos, o en uno, o en -4,294,967,295, o quién sabe qué otros valores (la propiedad se puede escribir utilizar valores de bloqueo de prevención distintos de uno o dos en ese escenario, pero no se pudo escribir para garantizar el incremento correcto en dos).

Answer 12

El uso de campos se practica generalmente en clases privadas que no están destinadas a compartir datos con otras clases. Cuando queremos que nuestros datos sean accesibles por otras clases usamos propiedades que tienen la capacidad de compartir datos con otras clases a través de get y set que son los métodos de acceso llamados Auto Properties que tienen acceso a datos en clases privadas, también puede usar ambos con modificadores de acceso en la misma clase permitiendo a la clase usar datos de forma privada como campo de datos y al mismo tiempo vincular el campo privado a una propiedad que hace que los datos también sean accesibles para otras clases, vea este ejemplo simple:

private string _name; 
public string Name  
{ 
    get 
    { 
     return _name; 
    } 
    set 
    { 
     _name = value; 
    } 
} 

The la cadena privada _name es usada solo por la clase, mientras que la propiedad Name es accesible por otras clases en el mismo espacio de nombres.