example - remarks c#

Campos públicos versus propiedades automáticas

Question

A menudo se nos dice que debemos proteger la encapsulación al crear métodos de obtención y establecimiento (propiedades en C #) para los campos de clase, en lugar de exponer los campos al mundo exterior.

Pero hay muchas veces cuando un campo está ahí para mantener un valor y no requiere ningún cálculo para obtener o establecer. Para estos todos haríamos este número:

public class Book
{
private string _title;
public string Title
{
get{ return _title; }
set{ _title = value; }
}
}

Bueno, tengo una confesión, no podía soportar escribir todo eso (en realidad, no tenía que escribirlo, tenía que mirarlo), así que fui malicioso y usé campos públicos.

Luego viene C # 3.0 y veo que agregaron propiedades automáticas:

public class Book
{
public string Title {get; set;}
}

que es más ordenado, y estoy agradecido por ello, pero en realidad, ¿qué es tan diferente a solo hacer un campo público?

public class Book
{
public string Title;
}

Answer 1

Cambiar de un campo a una propiedad rompe el contrato (por ejemplo, requiere que se recompile todo el código de referencia). Entonces, cuando tenga un punto de interacción con otras clases, cualquier miembro público (y generalmente protegido), desea planificar para el crecimiento futuro. Hazlo siempre usando propiedades.

No es nada para convertirlo en una propiedad automática hoy en día, y 3 meses después de la línea, se dará cuenta de que desea que se cargue de forma perezosa y ponga un cheque nulo en el receptor. Si ha utilizado un campo, este es un cambio de recompilación en el mejor de los casos y en el peor de los casos imposible, dependiendo de quién y qué más se basa en sus ensamblajes.

Answer 2

En una pregunta relacionada que tenía hace algún tiempo, había un enlace a una publicación en el blog de Jeff, explicando algunas diferencias.

Propiedades vs. Variables Públicas

• La reflexión funciona de manera diferente en las variables en comparación con las propiedades, por lo que si confía en la reflexión, es más fácil usar todas las propiedades.
• No puedes enlazar contra una variable.

• Cambiar una variable a una propiedad es un cambio importante. Por ejemplo:

  TryGetTitle(out book.Title); // requires a variable

Answer 3

Ignorando los problemas de la API, lo que encuentro más valioso sobre el uso de una propiedad es la depuración.

El depurador CLR no admite puntos de interrupción de datos (la mayoría de los depuradores nativos sí lo hacen). Por lo tanto, no es posible establecer un punto de interrupción en la lectura o escritura de un campo en particular en una clase. Esto es muy limitante en ciertos escenarios de depuración.

Debido a que las propiedades se implementan como métodos muy finos, es posible establecer puntos de interrupción en la lectura y escritura de sus valores. Esto les da una gran ventaja sobre los campos.

Answer 4

No hay nada de malo en hacer public un campo. Pero recuerde que la creación de getter/setter con campos private no es una encapsulación. En mi opinión, si no le importan otras características de una Property , también puede hacerlo public .

Answer 5

Otra ventaja de las propiedades implementadas automáticamente sobre los campos públicos es que puede hacer que los accesores de conjuntos sean privados o protegidos, proporcionando a la clase de objetos donde se definió un mejor control que el de los campos públicos.

Answer 6

Se trata de versionado y estabilidad API. No hay diferencia, en la versión 1, pero más adelante, si decide que necesita hacer de esto una propiedad con algún tipo de comprobación de errores en la versión 2, no tiene que cambiar su API; no hay cambios de código, en ninguna otra parte, excepto en La definición de la propiedad.

Answer 7

Si posteriormente decide verificar que el título es único, al compararlo con una colección o una base de datos, puede hacerlo en la propiedad sin cambiar ningún código que dependa de él.

Si solo usa un atributo público, tendrá menos flexibilidad.

La flexibilidad adicional sin romper el contrato es lo más importante para mí sobre el uso de propiedades y, hasta que realmente necesite la flexibilidad, la autogeneración tiene más sentido.

Answer 8

Solo porque nadie lo mencionó: no se pueden definir campos en Interfaces. Por lo tanto, si tiene que implementar una interfaz específica que define las propiedades, las propiedades automáticas a veces son una característica muy buena.

Answer 9

Una cosa que me parece muy útil, así como todo el código y las razones de las pruebas, es que si se trata de una propiedad frente a un campo es que el IDE de Visual Studio le muestra las referencias de una propiedad pero no un campo.

Answer 10

Una gran diferencia que a menudo se pasa por alto y no se menciona en ninguna otra respuesta: anulación . Puede declarar las propiedades virtuales y anularlas, mientras que no puede hacer lo mismo para los campos de miembros públicos.