Campos públicos versus propiedades automáticas

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

Pero hay muchas ocasiones en que un campo está ahí para contener 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 (realmente, no era tener que escribirlo, era tener que mirarlo), así que me volví pícaro y utilicé los campos públicos.

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

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

lo cual 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;
}

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

Propiedades frente a variables públicas

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

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

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

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

El depurador CLR no admite puntos de ruptura 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 delgados, es posible establecer puntos de interrupción en la lectura y escritura de sus valores. Esto les da una gran ventaja sobre los campos.

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

Hoy en día, no es nada para que sea una propiedad automática, y 3 meses después se dan cuenta de que desea hacerlo con carga perezosa y ponen un cheque nulo en el getter. Si ha utilizado un campo, este es un cambio de compilación en el mejor de los casos e imposible en el peor, dependiendo de quién y qué más depende de sus ensamblajes.

Solo porque nadie lo mencionó: no se pueden definir campos en las interfaces. Entonces, si tiene que implementar una interfaz específica que defina propiedades, las propiedades automáticas a veces son una característica realmente agradable.

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

Se trata de versiones y estabilidad de API. No hay diferencia, en la versión 1, pero más tarde, si decide que necesita convertir esto en una propiedad con algún tipo de verificación de errores en la versión 2, no tiene que cambiar su API, no hay cambios de código, en ningún otro lugar que no sea La definición de la propiedad.

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

No hay nada malo en hacer un campo public. Pero recuerde que crear getter/settercon privatecampos no es encapsulación. OMI, si no te interesan otras características de a Property, también podrías hacerlo public.

Si luego 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 elige solo 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 generación automática tiene más sentido.

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

Mi punto de vista después hizo algunas investigaciones

1. Validación.
2. Permitir reemplazar el descriptor de acceso para cambiar el comportamiento de una propiedad.
3. Propósito de depuración. Podremos saber cuándo y qué cambia la propiedad estableciendo un punto de interrupción en el descriptor de acceso.
4. Podemos tener un campo solo establecido. Por ejemplo, public set () y private get (). Esto no es posible con el campo público.

Realmente nos da más posibilidades y extensibilidad.