2009-04-21 11 views
17

¿Hay alguna diferencia interna entre el C# sintáctica forma de azúcar de la toma de propiedades:¿Está bien utilizar una variable pública en C# si es de solo lectura?

public string FirstName { get; set; } 

y sólo hacer las variables públicas como esto:

public string LastName; 

Asumo se prefiere la primera forma y la segunda a ser evitado Sin embargo, a menudo veo este tipo de propiedad de sólo lectura que se utiliza, que es una forma del segundo tipo anterior:

public readonly string InternalCode; 

Es de esta manera una mejor práctica para crear la propiedad de sólo lectura?

using System; 

namespace TestProps 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      Customer customer = new Customer(); 
      customer.FirstName = "Jim"; 
      customer.LastName = "Smith"; 
      customer.Show(); 
     } 
    } 

    class Customer 
    { 
     public string FirstName { get; set; } //prefered 
     public string LastName; //avoid 
     public readonly string InternalCode; //??? 

     public Customer() 
     { 
      InternalCode = "234729834723984"; 
     } 

     public void Show() 
     { 
      Console.WriteLine("{0}, {1} ({2})", LastName, FirstName, InternalCode); 
      Console.ReadLine(); 
     } 
    } 
} 

Respuesta

17

Puesto que él no respondió (aún) y nadie más hace referencia a esto todavía: Hay un gran artículo sobre este tema por Jon Skeet se modifica su libro C# en profundidad (dar créditos a Jon):

Why Properties Matter

+0

ese artículo consistía en dos páginas que abordaban directamente mi pregunta, ¡gracias! Entiendo por eso que Jon ni siquiera aprobaría el "público readwly bool IsValid"; a menos que, como lo menciona al final, esté en una clase anidada –

+1

Para aquellos de nosotros que solo buscan una respuesta y no un artículo extenso, ¿podrían agregar una alerta de spoiler aquí y darnos la respuesta sí o no? – DOK

+0

El artículo de Skeet en realidad hace un par de excepciones, una de las cuales podría aplicarse a esta pregunta. Según el artículo, "haré una pequeña excepción para campos estáticos de solo lectura como string.Empty". Esta pregunta pudo haber sido modificada y al mover la asignación desde el constructor a la misma línea se leería públicamente static string InternalCode = "234729834723984"; Como tal, sería un "campo de solo lectura estático" como describió Skeet. – John

1

Sí. está bien tener una variable pública de solo lectura (es solo que pueden inicializarse en el momento de la definición o el constructor).

p. Ej. Decimal.MaxValue

Tener propiedad pública de solo lectura es buena, si el valor de la copia de seguridad cambia (aparte de con lo que se inicializó).

p. Ej. Environment.TickCount

Pensé que Environment.NewLine será una variable pública de solo lectura. Bueno, es una propiedad pública (solo obtener) y la razón podría ser mantener la compatibilidad en diferentes plataformas.

+0

¿Qué pasa con esto? Por favor, publique el motivo cuando baja la votación. Me ayudará a darme cuenta de mi error. Gracias. – shahkalpesh

+0

No hay votos de mí, pero en realidad Decimal.MaxValue es una constante y no un campo de instancia (Lea el artículo de Jon Skeet vinculado en mi respuesta por razones de no exponer a los campos) –

3

El uso de una propiedad proporciona una interfaz que es más resistente al cambio en el futuro. Digamos que en algún momento en el futuro, se toma la decisión de agregar un prefijo al código interno.

El uso de una variable pública de solo lectura expone su estructura interna y le será difícil agregar el prefijo a cada línea que utilizó la variable interna de la clase.

utilizando una propiedad, sólo puede escribir el siguiente

public string InternalCode { 
    get { return _prefix + _internalCode; } 
} 

y ya está!

+0

Una vez que resuelva todos sus errores de compilación :-) Lo –

+0

errores del compilador? –

+0

Error El modificador 'readonly' no es válido para este artículo –

3

En mi opinión, está bien exponer los campos públicos (especialmente si son de solo lectura o const). Habiendo dicho eso, diría que en el ejemplo que presentas, probablemente iré con las propiedades, ya que te darán 2 ventajas (sobre los campos): 1) mejor encapsulación y puede permitirte adaptar tu código en el futuro y 2) si está haciendo enlace de datos, entonces necesita las propiedades.

0

respuesta corta: public const está bien sólo lectura, no necesariamente pública, obtener público sin fijar no necesariamente siempre. Los objetos que no pueden modificarse sin estar asignados pueden estar bien. Los tipos de referencia son peligrosos ya que aún puede cambiar sus valores, incluso si no puede cambiar la referencia en sí.

El problema con la palabra clave de sólo lectura es que esto no significa que lo que se entiende como lógicamente sólo lectura/inmutable. Significa más como "solo se puede asignar en el constructor". Las referencias no se pueden cambiar, pero sus valores sí pueden. No hay una palabra clave readonly "real" proporcionada por C#, desafortunadamente. Consulte también https://blogs.msdn.microsoft.com/ericlippert/2007/11/13/immutability-in-c-part-one-kinds-of-immutability/

Las propiedades no pueden tener la palabra clave readonly (https://titombo.wordpress.com/2012/11/11/using-the-c-modifiers/). Como han señalado otros, puede usar una propiedad y solo definir get y no set, aunque no puede establecer esa propiedad en el constructor. El uso de un conjunto privado, se puede establecer la propiedad de annywhere en la clase, no sólo en el constructor. El campo de solo lectura sería un poco más restrictivo.

Cuestiones relacionadas