Usando una variable de respaldo para getters y setters

Quizás esta es una pregunta tonta, sin embargo, soy razonablemente nuevo en C# (más de un fondo Java) y me confundí entre diferentes ejemplos que he visto sobre getters y setters de una propiedad .Usando una variable de respaldo para getters y setters

En algunas situaciones, el código es el siguiente:

private string _something; 
    public string Something 
    { 
     get { return _something; } 
     set { _something = value; } 
    }

Sin embargo, en otros ejemplos que no utilizan este memeber respaldo y por lo que es de la misma familia:

public string Something { get; set; }

no lo hago realmente veo el beneficio de usar estas variables de respaldo (_algo) a menos que, por supuesto, tenga alguna lógica compleja con respecto a la configuración de las variables.

Estoy escribiendo mi programa utilizando el último enfoque, pero quería comprobar que no me he perdido nada.

¿Puede alguien explicar por qué la gente eligió hacer lo primero? ¿Es más una 'buena práctica'?

¡Muchas gracias!

Fuente

2012-10-04 rioubenson

Supongo que la última es la definición del prototipo, como 'interface' en java. –

@SuzanCioc Nope. Es lo mismo, pero el compilador de C# implementa el campo de respaldo. –

Ah no, estoy equivocado. Esta es una nueva sintaxis que tiene una variable de respaldo implícita. –

Realmente no veo el beneficio de usar estas variables de respaldo (_algo) a menos que, por supuesto, tenga alguna lógica compleja con respecto a la configuración de las variables.

No hay ninguna ventaja si no lo estás usando. Con el segundo enfoque, todavía hay una variable de respaldo, pero está dejando que el compilador haga el trabajo de agregarlo. A partir de .NET 3.5 y posterior, su enfoque actual es perfectamente válido.

Por supuesto, tan pronto como necesite introducir una lógica extra, la gestión de la tienda de respaldo se vuelve crítica.

Fuente

2012-10-04 21:28:19

Entonces, ¿hay más sobrecarga para que el compilador haga el trabajo de agregarlo? – Riana

@AngelBrighteyes No, es exactamente lo mismo que si lo escribes tú mismo. Es solo menos tipeo. (y un nombre de campo generado por el compilador diferente) –

@AngelBrighteyes - Esto es solo un ejemplo de lo que se llama "azúcar sintáctico". Código más corto, pero opera exactamente de la misma manera detrás de la escena. –

La sintaxis anterior era necesaria antes de .NET 3.5 y, por lo tanto, se encuentra en el código anterior.

Es funcionalmente equivalente.

Fuente

2012-10-04 21:27:51

Perfecto, gracias por la rápida respuesta! – rioubenson

cadena pública Something {get; conjunto; } es solo de corta duración. en el fondo, está haciendo exactamente lo mismo que arriba.

Fuente

2012-10-04 21:28:12 twaldron

Una buena razón para usar la primera sintaxis es para usar con arquitecturas MVVM donde sus propiedades están ligadas a elementos frontales.

Algo así como:

private string _something; 
    public string Something 
    { 
     get { return _something; } 
     set { 
       _something = value; 
       OnNotifyPropertyChanged("Something"); 
      } 
    }

Eso sería alertar a su extremo delantero que su propiedad cota se ha cambiado y tiene que actualizar.

Fuente

2012-10-04 21:30:07

Ah, esto tal vez sea exactamente lo que he estado viendo. Estoy intentando construir mi aplicación utilizando la arquitectura MVVC, así que he usado muchos tutoriales para entenderlo. Sospecho que aquí es donde se ha originado mi confusión. Gracias. – rioubenson

enfoque seconde es Auto-Implement Property

Fuente

2012-10-04 21:30:11

referencia a propiedades automáticas desde el interior de la instancia es la misma que la que se declara un campo público, lo que rompe el Encapsulation Principle. Por lo tanto, use propiedades automáticas si no accede a ellas dentro de la misma clase. De lo contrario, use un campo miembro (de respaldo) y haga referencia a eso desde sus métodos locales mientras los expone a través de una propiedad .NET normal.

Las propiedades automáticas se agregaron con .NET 3.0 como azúcar sintáctico por lo que ya no necesita campos de respaldo que no estén referenciados dentro de su clase.

Fuente

2012-10-04 21:37:15 hyru

Usando una variable de respaldo para getters y setters

Respuesta

Cuestiones relacionadas