È possibile forzare una proprietà automatica per utilizzare un campo di backup di sola lettura?

Question

Il mio progetto contiene un numero elevato di classi con proprietà il cui campo di supporto è contrassegnato in sola lettura in quanto sono impostati solo in fase di costruzione. Per questioni di stile, mi piace usare le proprietà automatiche poiché elimina un sacco di codice di codice e incoraggia l'uso del membro della proprietà piuttosto che del campo di supporto. Tuttavia, quando si utilizza una proprietà automatica, perdo la "readonlyness" del mio campo di supporto. Capisco il compilatore/runtime è in grado di approfittare di alcuni miglioramenti delle prestazioni quando un campo è contrassegnato in questo modo, quindi mi piacerebbe essere in grado di marcare la mia auto-proprietà come sola lettura, qualcosa di simile:

[ReadOnly] 
public string LastName { get; } 

piuttosto che

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

C'è qualche meccanismo già disponibile per farlo? In caso contrario, il guadagno prestazionale dal backing field personalizzato è di sola lettura davvero utile?

L'esposizione del campo come pubblica è un'altra opzione, suppongo, non sembra giusto esporre un campo in questo modo. vale a dire

public readonly string LastName; 

Answer 1

non ho paura, ma si può fare questo:

public string LastName { get; private set; } 

Non abbastanza buono come readonly, ma non troppo male.

Answer 2

No non lo è e se fosse la funzionalità sarebbe inutile senza modifiche significative.

Un campo di sola lettura può essere impostato in modo verificabile solo da un costruttore. Una proprietà auto-implementata può essere impostata solo dal setter generato. Questi sono requisiti incompatibili e produrranno codice non verificabile.

Sì, si potrebbe potenzialmente rendere il compilatore abbastanza intelligente da ignorare il setter e passare direttamente al campo di supporto nel costruttore. Ma nel setter stesso sarebbe ancora non verificabile. Il compilatore dovrebbe ometterlo dal codice generato poiché produrrà una proprietà di sola lettura. Questo produce un'altra contraddizione perché avresti ancora bisogno di fare una dichiarazione di assegnazione contro la proprietà.

Foo() { 
    SomeProperty = "somevalue"; 
} 

In questo caso il codice sembra chiamare un setter su una proprietà. Ma in realtà non c'è un setter da chiamare dal momento che deve essere omesso dal codice finale.

EDIT

Questo non sta dicendo che non può essere fatto. Può, ma richiederebbe un po 'di lavoro da C#.

In particolare, dovrebbero fornire un modo per impostare il campo di appoggio di una proprietà che non può avere un setter. Ci sono diversi modi in cui ciò potrebbe essere fatto.

• Dare agli utenti l'accesso al campo di appoggio di una proprietà auto-implementato
• Consentire la sintassi stile setter, anche se non v'è alcuna setter e lasciare che il compilatore traduce in un accesso di campo sotto il cofano
• Invent qualche nuova sintassi

Non sto dicendo che alcune di queste sono buone opzioni, solo possibilità di fare funzionare questo tipo di funzionalità.

Answer 3

Preferisco il vero campo di supporto readonly, poiché questo garantisce che non sto cambiando quel campo di supporto dopo la costruzione.

Answer 4

No e no. Non c'è modo di farlo e non c'è alcun guadagno in termini di prestazioni per supportare i campi di sola lettura.

Answer 5

No, sfortunatamente non c'è modo di farlo. Personalmente ci sono due cose che penso manchino dalle proprietà implementate automaticamente in C# - un valore predefinito (che credo sarà in VB10) e proprietà readonly che possono essere impostate solo nel costruttore. In altre parole, mi piacerebbe essere in grado di fare:

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; 
    } 
} 

Come detto Jared, questo significherebbe cambiare le chiamate del compilatore per il setter di proprietà in semplici assegnazioni dei campi, e fare in modo che si sono verificati solo nel costruttore.

Ciò renderebbe la scrittura di tipi immutabili più semplice. Purtroppo la situazione non migliorerà nel C# 4. Speriamo di ottenere qualcosa del genere per C# 5 ...

Answer 6

A partire da C# 6.0 la risposta è sì. Il tuo esempio può essere scritto come sotto, e il compilatore genera automaticamente un campo di sola lettura dietro la proprietà. Questa è chiamata una proprietà auto-solo getter.

public string LastName { get; } 

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

Getter sola auto-proprietà sono disponibili in entrambe le strutture e le classi dichiarazioni, ma sono particolarmente importanti per le strutture a causa della linea guida di miglior pratica che le strutture essere immutabili . Piuttosto che la sei o più righe necessarie per dichiarare una proprietà di sola lettura e inizializzare prima di C# 6.0, ora una dichiarazione a riga singola e l'assegnazione all'interno del costruttore sono tutto ciò che è necessario. Pertanto, la dichiarazione di strutture immutabili ora non è solo il modello di programmazione corretto per le strutture, ma anche lo schema più semplice, una modifica molto apprezzata da una sintassi precedente in cui la codifica richiedeva uno sforzo maggiore.