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

Question

me he dado cuenta de que el C# propiedad constructo también se puede utilizar con un modificador privada acceso:

private string Password { get; set; } 

Aunque esto es técnicamente interesante, no me puedo imaginar cuando lo uso ya que un ámbito privado implica incluso menos ceremonia:

private string _password; 

y no puedo imaginar que cuando alguna vez necesito estar poder internamente obtener pero no conjunto o conjunto pero no obtener un campo privado:

private string Password { get; } 

o

private string Password { set; } 

pero tal vez no es un caso de uso con clases anidadas/heredadas o quizás cuando get/set puede contener lógica en lugar de simplemente devolver el valor de la propiedad, aunque tendería a mantener las propiedades estrictamente simples y permitir que los métodos explícitos hagan cualquier lógica, p. GetEncodedPassword().

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

Adición

Niza respuestas, leer a través de ellos que sacrificaron estos usos para las propiedades privadas:

• cuando los campos privados necesitan ser cargados de forma liviana
• cuando los campos privados necesitan lógica adicional o se calculan valores
• ya que los campos privados pueden ser difíciles de depurar
• para "presentar un contrato a usted mismo"
• para convertir internamente/simplificar una propiedad expuesta como parte de serialización
• envolviendo variables globales para ser utilizado dentro de su clase

Answer 1

Los uso si necesito guardar 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 2

yo los utilizo cada vez en cuando. Pueden facilitar la depuración de situaciones 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 luego necesita cambiar el tipo de datos en algunas manera o si necesita usar la reflexión.

Answer 3

tal vez no es un caso de uso con clases anidadas/heredadas o tal vez en un get/set puede contener lógica en lugar de simplemente devolviendo el valor de la propiedad

Yo personalmente uso esto incluso cuando no necesita lógica en el getter o setter de una propiedad. El uso de una propiedad, incluso una privada, ayuda a proteger su código a futuro para que pueda agregar la lógica a un getter más tarde, si es necesario.

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

---

En un caso semi-relacionados (aunque diferente a su pregunta), que muy a menudo utilizan los emisores privados en las propiedades públicas:

public string Password 
{ 
    get; 
    private set; 
} 

Esto le da un captador pública, pero mantiene la incubadora privado.

Answer 4

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

Answer 5

Tiene mucho sentido cuando hay una lógica asociada con el conjunto de propiedades o get (piense en la inicialización lenta) y la propiedad se usa en algunos lugares de la clase.

Si es solo un campo de respaldo recto? Nada viene a la mente como una buena razón.

Answer 6

El único uso que se me ocurre

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

Answer 7

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

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

Answer 8

La inicialización diferida es un lugar donde pueden estar ordenadas, p. Ej.

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; 

A continuación, se puede escribir: this.MyType todas partes en lugar de this.mytype.Value y encapsular el hecho de que se crea una instancia perezosamente en un solo lugar.

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

Answer 9

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

Answer 10

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

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. Frecuentemente quiero saber cosas como "este campo se está configurando inesperadamente, ¿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 "ir". Puedes poner logging allí. Puedes poner métricas de rendimiento allí. Puede colocar comprobaciones de coherencia que se ejecutan en la compilación de depuración.

Básicamente, se trata de: 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 le permiten escribir código en ellos, las propiedades sí.

Answer 11

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

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

Answer 12

Una cosa que hago todo el tiempo es tienda de las variables "globales"/cache 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 13

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

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

Es útil si hay muchas propiedades secundarias.