¿Por qué debería usar una variable privada en un descriptor de acceso a la propiedad?

Question

Disculpa Si estoy siendo novato, tengo esta duda, ¿por qué utilizamos variables privadas y las configuramos usando propiedades?

¿Por qué no podemos simplemente usar los derechos solos?

Estoy hablando de situaciones como esta

private string _testVariable; 

public string MyProperty 
{ 
    get { return _testVariable;} 
    set {_testVariable = value;} 
} 

que estoy pensando simplemente usando

public string MyProperty { get; set; } 

Por qué redundante variable privada? ¿Son estas dos estrategias diferentes? ¿Alguien puede arrojar algo de luz sobre esto?

Gracias

Answer 1

Sus ejemplos son semánticamente iguales. La sintaxis concisa de declaración de propiedad (solo tiene { get; set; }) es un atajo disponible en C# 3.0. El compilador realmente crea una variable de respaldo privada y un getter y setter simple como en su primer ejemplo.

Si todo lo que hace es crear un getter y setter (y en realidad no ocurre nada cuando ocurre), entonces la sintaxis concisa es una buena opción. Si tiene que realizar cualquier otra acción (redibujar un control, por ejemplo) cuando establece el valor, entonces se requiere la sintaxis completa.

Answer 2

El segundo ejemplo que das:

public string MyProperty { get; set; } 

sólo está disponible en las versiones posteriores de .NET Framework (versión 3.0 en adelante creo)

El primer ejemplo permite usted puede establecer puntos de interrupción en el return y declaraciones de asignación, lo que hace que su depurador se rompa cuando se asigna/lee la propiedad.

Answer 3

El primer fragmento de código le permite modificar algún estado de clase privado. Envolver el estado privado en una propiedad es bueno porque oculta la implementación. Más tarde puede cambiar la implementación y la propiedad (interfaz externa) puede permanecer sin cambios.

Por ejemplo, supongamos que en lugar de establecer una sola cadena dentro del setter, configura la cadena en un almacén privado de algún tipo. Usted lo escribe en un archivo, o lo escribe en la memoria compartida. O tal vez calcule el hash de la cadena solamente, y no lo almacene en absoluto, como podría hacer con una contraseña.

Las propiedades automáticas en su segundo fragmento de código no están relacionadas con la variable privada en absoluto. El diseño de propiedad automática, como el diseño de propiedad explícito utilizado en el primer recorte, permite futuras modificaciones. Como parte de esa modificación, por ejemplo, puede convertir propiedades automáticas en propiedades explícitamente implementadas.

Answer 4

La propiedad es básicamente la envoltura alrededor de un campo. Este contenedor permite usar la variable del mundo exterior. En C# 3.0 puede simplemente declarar una propiedad como public string MyProperty { get; set; } El compilador declara una variable privada automáticamente y también establece métodos para eso. Si necesita realizar cualquier cálculo dentro de la clase que declara la propiedad, entonces debe usar el campo privado para eso.

Answer 5

A veces no sabe cuándo escribe el código por primera vez, si puede agregar más código más tarde que necesite usar la variable privada. Claro, puedes agregarlo más tarde si es necesario. Simplemente creo automáticamente la variable privada, suponiendo que se usará más tarde.

Esto puede ser más relevante en aplicaciones de grandes empresas o aplicaciones de rápida evolución (ágiles) donde la implementación completa puede no conocerse durante la codificación inicial.

Answer 6

¿Por qué variable privada redundante? son estas dos estrategias diferentes? puede alguien por favor arroja algo de luz sobre esto.

Si todo lo que hace es leer/escribir una variable, entonces no. De lo contrario, hay dos razones por las que querría una variable privada:

La validación de datos

// Data validation 
public class IntWrapper 
{ 
    private int _value; 
    public int Value 
    { 
     get { return _value; } 
     set 
     { 
      if (value < 0) { throw new Exception("Value must be >= 0"); } 
      _value = value; 
     } 
    } 
} 

captador/envuelve un almacén de datos subyacente

public class StringBuffer 
{ 
    List<char> chars = new List<char>(); 

    // Wraps up an underlying data store 
    public string Value 
    { 
     get { return new String(chars.ToArray()); } 
     set { chars = new List<char>(value.ToCharArray()); } 
    } 

    public void Write(string s) { Write(chars.Count, s); } 

    public void Write(int index, string s) 
    { 
     if (index > chars.Count) { throw new Exception("Out of Range"); } 
     foreach(char c in s) 
     { 
      if (index < chars.Count) { chars[index] = c; } 
      else { chars.Add(c); } 
      index++; 
     } 
    } 
} 

Answer 7

Mashesh, ¡Todos teníamos que comenzar en algún lado! Usted preguntó por VARs privadas vs propiedades con este ejemplo:

private string _testVariable; 

public string MyProperty 
{ 
    get { return _testVariable;} 
    set {_testVariable = value;} 
} 

-or- 

public string MyProperty { get; set; } 

¿Consideró:

public string MyProperty { get; private set; } 

Usted puede aplicar alcance de getters/setters de propiedad. . . . cosas interesantes. Oh si . . . al usar este tipo de propiedad dentro de la clase definitoria (como en un constructor) anteponerla con un 'esto'. - por lo que una asignación se vería como 'this.MyProperty = "Una cadena asignada";'. Esto hace que sus intenciones mucho más claro. . .

Answer 8

Esto no está relacionado con C# el langugage, pero más la aplicación.

Una razón para usar propiedades es que se trata como "Especial" en muchos frameworks. Por ejemplo, Silverlight y WPF se vincularán a las propiedades y no a los campos

Answer 9

ODIO las variables de respaldo cuando no son necesarias, causa más complejidad que la necesaria.

Obviamente, si tiene la necesidad de hacer algo especial en el captador o colocador, se debe utilizar la forma semántica completa y no el azúcar.

También me gusta usar las propiedades como un método para depurar cómo se establece la propiedad o la usa, a veces esto no es tan obvio debido a la reflexión y esa es una de las razones por las que me gusta usarlas.

Me resulta frustrante intentar depurar código cuando existe la posibilidad de que la variable de respaldo pueda acceder internamente en la clase por la propia propiedad o la variable de respaldo y nada le dice al codificador el camino correcto para acceder.

Puede acceder a la variable de respaldo internamente, así como a la propiedad, ¿cuál es la manera correcta? No es obvio ...