¿Es posible forzar una propiedad automática para utilizar un campo de respaldo de solo lectura?

Question

Mi proyecto contiene una gran cantidad de clases con propiedades cuyo campo de respaldo está marcado como "solo lectura", ya que solo se configuran en la construcción. Como una cuestión de estilo, me gusta usar auto-propiedades, ya que elimina una gran cantidad de código repetitivo y alienta el uso del miembro de la propiedad en lugar del campo de respaldo. Sin embargo, cuando uso una propiedad automática, pierdo la "capacidad de lectura" de mi campo de respaldo. Yo entiendo que el compilador/tiempo de ejecución es capaz de tomar ventaja de algunas mejoras en el rendimiento cuando un campo está marcado de esta manera, así que me gustaría ser capaz de marcar mi auto-propiedad como de sólo lectura, algo como esto:

[ReadOnly] 
public string LastName { get; } 

en lugar de

private readonly string _LastName; 
public string LastName 
{ 
    get 
    { 
     return _LastName; 
    } 
} 

¿Hay algún mecanismo disponible para hacer esto? De lo contrario, ¿es realmente útil la ganancia de rendimiento del campo de respaldo personalizado?

Exponer el campo como público es otra opción, supongo, parece incorrecto exponer un campo de esa manera. es decir,

public readonly string LastName; 

Answer 1

no tengo miedo, pero se puede hacer esto:

public string LastName { get; private set; } 

No es tan bueno como readonly, pero no demasiado malo.

Answer 2

No, no lo es y, si fuera así, sería inútil sin ajustes significativos.

Un campo de solo lectura solo se puede establecer verificablemente desde un constructor. Una propiedad implementada automáticamente solo se puede configurar desde el setter generado. Estos son requisitos incompatibles y producirán código no verificable.

Sí, podría hacer que el compilador sea lo suficientemente inteligente como para ignorar al colocador e ir directamente al campo de respaldo en el constructor. Pero en el setter en sí mismo aún no sería verificable. El compilador necesitaría omitirlo del código generado así como producir una propiedad verdaderamente de solo lectura. Esto produce otra contradicción porque aún tendría que hacer una declaración de asignación en contra de la propiedad.

Foo() { 
    SomeProperty = "somevalue"; 
} 

En este caso, el código parece que está llamando a un colocador en una propiedad. Pero en realidad no se debe llamar a ningún setter ya que debe omitirse del código final.

EDITAR

Esto no quiere decir que no se puede hacer. Puede, pero requeriría un poco de trabajo de C#.

En particular, tendrían que proporcionar una forma de establecer el campo de respaldo de una propiedad que no puede tener un colocador. Hay varias formas en que esto se puede hacer.

• dar a los usuarios el acceso al campo respaldo de una propiedad de auto-aplicado
• Permitir la sintaxis de estilo de la moda a pesar de que no existe una incubadora y dejar que el compilador traducirlo a un acceso en campo bajo el capó
• Inventar alguna sintaxis nueva

No estoy diciendo que estas sean buenas opciones, solo posibilidades de hacer que este tipo de característica funcione.

Answer 3

Prefiero el campo de respaldo real readonly, ya que esto garantiza que no cambiaré ese campo de respaldo después de la construcción.

Answer 4

No y no. No hay forma de hacerlo y no hay ganancia de rendimiento para los campos de respaldo de solo lectura.

Answer 5

No, lamentablemente no hay forma de hacerlo. Personalmente hay dos cosas que creo que faltan en las propiedades implementadas automáticamente en C#: un valor predeterminado (que creo que estará en VB10) y propiedades de solo lectura que solo se pueden establecer en el constructor. En otras palabras, me gustaría ser capaz de hacer:

public class Foo 
{ 
    public string Tag { get; internal set; } = "Default value"; 

    // The "readonly" would imply "private" as it could only 
    // be set from a constructor in the same class 
    public int Value { get; readonly set; } 

    public Foo() 
    { 
     // Valid to set property here, but nowhere else 
     Value = 20; 
    } 
} 

Como se mencionó Jared, esto significaría cambiar las llamadas compilador del organismo emisor de la propiedad en las tareas de campo simples, y asegurarse de que sólo se produjeron en el constructor.

Esto haría que escribir tipos inmutables sea más simple. Desafortunadamente la situación no mejorará en C# 4. Esperemos que obtengamos algo como esto para C# 5 ...

Answer 6

A partir de C# 6.0 la respuesta es sí. Su ejemplo se puede escribir de la siguiente manera, y el compilador genera automáticamente un campo de solo lectura detrás de la propiedad. Esto se conoce como auto-propiedad getter-only.

public string LastName { get; } 

De https://msdn.microsoft.com/en-us/magazine/dn879355.aspx

Getter sólo auto-propiedades están disponibles en ambas estructuras y clase declaraciones, pero son especialmente importantes a causa de estructuras la guía de buenas prácticas que estructuras inmutables . En lugar de aproximadamente seis líneas necesarias para declarar una propiedad de solo lectura e inicializarla antes de C# 6.0, ahora una declaración de una sola línea y la asignación desde el constructor son todo lo que se necesita. Por lo tanto, la declaración de estructuras inmutables ahora no solo es el patrón de programación correcto para las estructuras, sino también el patrón más simple, un cambio muy apreciado de sintaxis anterior donde la codificación requería correctamente más esfuerzo.