Aprender acerca de las propiedades auto-implementadas

Question

Tengo la clase simple que utiliza propiedades implementadas automáticamente:

Public Class foo
{
    public foo() { }  

    public string BarName {get; set;}
}

Obviamente, uso la variable BarName en toda mi clase y ahora necesito agregar lógica cuando se establece el valor de la propiedad (debe estar todo en mayúsculas, vaya a la figura). ¿Esto significa que ahora necesito crear una variable privada para BarName, por ejemplo? _BarName, y cambiar la variable de BarName actual utilizada en mi clase a _BarName?

Public Class foo
{
    public foo() {}  

    private string _BarName = "";
    public string BarName 
    { 
        get {return _BarName;}
        set {_BarName = Value.ToString().ToUpper();}
    }
}

Estoy tratando de asegurarme de que entiendo las implicaciones de usar las propiedades implementadas automáticamente, y lo que implicará en el futuro cuando / si necesito cambiar algo. Supongo que la refactorización, como se muestra arriba, no es un rompiendo cambio porque la propiedad es básicamente igual; solo tomó un poco de trabajo dentro de la clase para mantenerlo así y agregar la lógica necesaria.

Otro ejemplo, que puede ser más significativo es que necesito llamar a algún método cuando se usa un setter o getter; Más que cambiar el valor.

Esto parece un intercambio justo de las líneas y líneas de código para configurar las propiedades.

Answer 1

  

¿Significa esto que necesito ahora?   crear una variable privada para BarName

Sí

  

y cambia el BarName actual   variable utilizada en mi clase

No cambie el resto del código de su clase para usar la nueva variable privada que cree. BarName , como una propiedad, está destinada a ocultar la variable privada (entre otras cosas), con el fin de evitar los cambios radicales que contempla el resto de su código.

  

Estoy asumiendo que la refactorización, como   mostrado arriba, no es un cambio de ruptura   porque la propiedad es básicamente   quedando igual solo tomó un   Poco trabajo para mantenerlo así y   agrega la lógica necesaria.

Correcto.

Answer 2

No necesitas cambiar nada. Las propiedades auto-implementadas son solo azúcar sintáctica. El compilador está generando la variable privada y obtiene / establece la lógica para usted, entre bastidores. Si agrega su propia lógica getter / setter, el compilador usará su código en lugar de su código generado automáticamente, pero en lo que respecta a los usuarios de esa propiedad, nada ha cambiado; cualquier código que haga referencia a su propiedad seguirá funcionando.

Answer 3

Al usar propiedades automáticas, no obtiene acceso directo al " respaldo; quot quot " variable y no obtiene acceso a la lógica real que se implementa en la propiedad getter and setter. Solo tiene acceso a la propiedad (por lo tanto, utilice BarName en todo su código).

Si ahora necesita implementar una lógica específica en el configurador, ya no puede usar las propiedades automáticas y necesita implementar la propiedad en el " antiguo " camino. En este caso, necesitaría implementar su propia variable de respaldo privado (el método preferido, al menos para mí, es nombrar a la variable de respaldo privado con el mismo nombre que la propiedad, pero con una minúscula inicial (en este caso, el respaldo la variable se llamaría barName). Luego implementaría la lógica apropiada en el getter / setter.

En tu ejemplo, tienes razón en que no es un cambio importante. Este tipo de refactorización (pasar de las propiedades automáticas a las propiedades " normal " nunca debe ser un cambio importante ya que no está cambiando la interfaz pública (el nombre o la accesibilidad de la propiedad pública).

Answer 4

No utilice propiedades automáticas si sabe que va a validar ese objeto. Estos objetos pueden ser objetos de dominio, etc. Al igual que si tiene una clase de Cliente, entonces use variables privadas porque podría necesitar validar el nombre, fecha de nacimiento, etc. Pero si está usando una clase Rss, estará bien simplemente usar las propiedades automáticas ya que no se realiza ninguna validación y la clase solo se utiliza para contener algunos datos.

Answer 5

Usted tiene razón acerca de la refactorización y realmente no debería romper nada.

Si realmente necesita o no pasar por las referencias dentro de la clase al nombre de la propiedad y cambiarlas para que se refieran al campo privado dependería de si el código interno necesario para acceder a la representación subyacente de los datos en lugar de cómo Se presentó a los consumidores de la clase. En la mayoría de los casos se podría dejar bastante bien solo.

En su ejemplo simple, sería prudente dejarlo lo suficientemente bien y asegurarse de que ningún código interno de la clase pueda subvertir la conversión / formateo que se realiza en el configurador.

Si, por otro lado, el captador estaba haciendo algo de magia para cambiar la representación interna del campo en la forma en que los consumidores necesitaban ver los datos, entonces quizás (en algunos casos) el código interno dentro de la clase necesitaría acceder al campo .

Debería mirar cada vez que ocurra el acceso a la propiedad automática en la clase y decidir si debe tocar el campo o usar la propiedad.

Answer 6

Las propiedades automáticas son solo azúcar sintáctica, de hecho, el compilador crea el miembro privado para ella, pero como se genera en el momento de la compilación, no puede acceder a ella.

Y más adelante, si desea implementar captadores y definidores para la propiedad, solo entonces creará un miembro privado explícito para él y agregará la lógica.