una - propiedades c# get set

¿Hay alguna razón para usar propiedades privadas en C#?

Question

Acabo de darme cuenta de que la construcción de la propiedad C # también se puede usar con un modificador de acceso privado :

private string Password { get; set; }

Aunque esto es técnicamente interesante, no puedo imaginar cuándo lo usaría, ya que un campo privado implica aún menos ceremonia :

private string _password;

y no puedo imaginar cuándo necesitaría poder obtener internamente pero no establecer o establecer un campo privado:

private string Password { get; }

o

private string Password { set; }

pero quizás exista un caso de uso con clases anidadas / heredadas o quizás un método get / set pueda contener lógica en lugar de devolver el valor de la propiedad, aunque tiendo a mantener las propiedades estrictamente simples y dejar que los métodos explícitos hagan cualquier lógica, por ejemplo, GetEncodedPassword() .

¿Alguien usa propiedades privadas en C # por alguna razón o es solo una de esas construcciones de código reales técnicamente posibles pero que rara vez se utilizan?

Apéndice

Buenas respuestas, al leerlas, eliminé estos usos para propiedades privadas:

• cuando los campos privados necesitan ser cargados perezosamente
• Cuando los campos privados necesitan lógica adicional o son valores calculados.
• ya que los campos privados pueden ser difíciles de depurar
• para "presentarte un contrato a ti mismo"
• para convertir / simplificar internamente una propiedad expuesta como parte de la serialización
• Envolver las variables globales que se utilizarán dentro de su clase

Answer 1

quizás exista un caso de uso con clases anidadas / heredadas o tal vez donde un get / set pueda contener lógica en lugar de devolver el valor de la propiedad

Personalmente uso esto incluso cuando no necesito lógica en el getter o setter de una propiedad. El uso de una propiedad, incluso una privada, ayuda a proteger su código para el futuro, de modo que puede agregar la lógica a un captador más adelante, si es necesario.

Si creo que una propiedad puede requerir una lógica adicional, a veces la incluiré en una propiedad privada en lugar de usar un campo, solo para no tener que cambiar mi código más adelante.

En un caso semi-relacionado (aunque diferente a su pregunta), uso con mucha frecuencia los setters privados en propiedades públicas:

public string Password
{
get;
private set;
}

Esto te da un captador público, pero mantiene el setter en privado.

Answer 2

Bueno, como nadie lo mencionó, puede usarlo para validar datos o bloquear variables.

• Validación

  string _password;
  string Password
  {
  get { return _password; }
  set
  {
  // Validation logic.
  if (value.Length < 8)
  {
  throw new Exception("Password too short!");
  }
  _password = value;
  }
  }

• Cierre

  object _lock = new object();
  object _lockedReference;
  object LockedReference
  {
  get
  {
  lock (_lock)
  {
  return _lockedReference;
  }
  }
  set
  {
  lock (_lock)
  {
  _lockedReference = value;
  }
  }
  }

  Nota: Al bloquear una referencia, no bloquea el acceso a los miembros del objeto al que se hace referencia.

Referencia perezosa: al cargar de forma perezosa, es posible que tenga que hacerlo de forma asíncrona, por lo que hoy en día existe AsyncLazy . Si tiene una versión anterior a la de Visual Studio SDK 2015 o no la está utilizando, también puede usar AsyncLazy de AsyncEx .

Answer 3

El único uso que se me ocurre

private bool IsPasswordSet
{
get
{
return !String.IsNullOrEmpty(_password);
}
}

Answer 4

El uso principal de esto en mi código es la inicialización perezosa, como han mencionado otros.

Otra razón para las propiedades privadas sobre los campos es que las propiedades privadas son mucho, mucho más fáciles de depurar que los campos privados. Con frecuencia, quiero saber cosas como "este campo se establece de forma inesperada; ¿quién es el primer interlocutor que establece este campo?" y es mucho más fácil si puedes poner un punto de interrupción en el setter y presionar go go. Usted puede poner el registro allí. Puedes poner métricas de rendimiento allí. Puede poner en las comprobaciones de coherencia que se ejecutan en la compilación de depuración.

Básicamente, todo se reduce a: el código es mucho más poderoso que los datos . Cualquier técnica que me permita escribir el código que necesito es buena. Los campos no te permiten escribir código en ellos, las propiedades sí.

Answer 5

Es una práctica común modificar solo miembros con métodos get / set, incluso los privados. Ahora, la lógica detrás de esto es que usted sabe que su conjunto / comportamiento siempre se comporta de una manera particular (por ejemplo, eventos de activación) que no parece tener sentido ya que no se incluirán en el esquema de propiedad ... Pero los viejos hábitos mueren duro.

Answer 6

La inicialización perezosa es un lugar donde pueden estar ordenados, por ejemplo

private Lazy<MyType> mytype = new Lazy<MyType>(/* expensive factory function */);
private MyType MyType { get { return this.mytype.Value; } }
// In C#6, you replace the last line with: private MyType MyType => myType.Value;

Luego, puede escribir: this.MyType cualquier lugar, no en this.mytype.Value y this.mytype.Value el hecho de que se crea una instancia perezosa en un solo lugar.

Una cosa que es una vergüenza es que C # no admite el alcance del campo de respaldo a la propiedad (es decir, declararlo dentro de la definición de la propiedad) para ocultarlo completamente y garantizar que solo se pueda acceder a él a través de la propiedad.

Answer 7

Las propiedades y los campos no son uno a uno. Una propiedad se refiere a la interfaz de una clase (ya se trate de su interfaz pública o interna), mientras que un campo se refiere a la implementación de la clase. Las propiedades no deben verse como una forma de exponer campos, sino que deben verse como una forma de exponer la intención y el propósito de la clase.

Al igual que usa las propiedades para presentar un contrato a sus consumidores sobre lo que constituye su clase, también puede presentarse un contrato a usted mismo por razones muy similares. Así que sí, uso propiedades privadas cuando tiene sentido. A veces, una propiedad privada puede ocultar los detalles de la implementación, como la carga lenta, el hecho de que una propiedad es realmente un conglomerado de varios campos y aspectos, o que una propiedad necesita ser virtualmente instanciada con cada llamada (piense en DateTime.Now ). Definitivamente hay momentos en los que tiene sentido imponer esto incluso en uno mismo en el backend de la clase.

Answer 8

Los uso de vez en cuando. Pueden facilitar la depuración de las cosas cuando puede colocar fácilmente un punto de interrupción en la propiedad o puede agregar una declaración de registro, etc.

También puede ser útil si más tarde necesita cambiar el tipo de sus datos de alguna manera o si necesita usar la reflexión.

Answer 9

Los uso en serialización, con cosas como DataContractSerializer o protobuf-net que admiten este uso ( XmlSerializer no). Es útil si necesita simplificar un objeto como parte de la serialización:

public SomeComplexType SomeProp { get;set;}
[DataMember(Order=1)]
private int SomePropProxy {
get { return SomeProp.ToInt32(); }
set { SomeProp = SomeComplexType.FromInt32(value); }
}

Answer 10

Los uso si necesito almacenar un valor en caché y quiero cargarlo de forma perezosa.

private string _password;
private string Password
{
get
{
if (_password == null)
{
_password = CallExpensiveOperation();
}
return _password;
}
}

Answer 11

Tiene mucho sentido cuando hay una lógica asociada con el conjunto de propiedades u obtención (piense que la inicialización es lenta) y la propiedad se utiliza en algunos lugares de la clase.

¿Si es solo un campo de apoyo directo? Nada viene a la mente como una buena razón.

Answer 12

Un buen uso para obtener propiedades privadas solo son valores calculados. Varias veces he tenido propiedades que son privadas de solo lectura y solo hago un cálculo sobre otros campos de mi tipo. No es digno de un método y no es interesante para otras clases, por lo que es propiedad privada.

Answer 13

Una cosa que hago todo el tiempo es almacenar variables "globales" / caché en HttpContext.Current

private static string SomeValue{
get{
if(HttpContext.Current.Items["MyClass:SomeValue"]==null){
HttpContext.Current.Items["MyClass:SomeValue"]="";
}
return HttpContext.Current.Items["MyClass:SomeValue"];
}
set{
HttpContext.Current.Items["MyClass:SomeValue"]=value;
}
}

Answer 14

Uso propiedades privadas para reducir el código para acceder a las propiedades secundarias que a menudo debo usar.

 private double MonitorResolution
{
get { return this.Computer.Accesories.Monitor.Settings.Resolution; }
}

Es útil si hay muchas sub propiedades.