Quali sono i vantaggi di contrassegnare un campo come "di sola lettura" in C #?

Quali sono i vantaggi di avere una variabile membro dichiarata come sola lettura? Sta solo proteggendo da qualcuno che cambia il suo valore durante il ciclo di vita della classe o l'utilizzo di questa parola chiave comporta miglioramenti della velocità o dell'efficienza?

La readonlyparola chiave viene utilizzata per dichiarare una variabile membro una costante, ma consente di calcolare il valore in fase di esecuzione. Ciò differisce da una costante dichiarata con il constmodificatore, che deve avere il valore impostato al momento della compilazione. Usando readonlypuoi impostare il valore del campo nella dichiarazione o nel costruttore dell'oggetto di cui fa parte il campo.

Usalo anche se non vuoi ricompilare DLL esterne che fanno riferimento alla costante (poiché viene sostituita al momento della compilazione).

Non credo ci siano miglioramenti delle prestazioni usando un campo di sola lettura. È semplicemente un controllo per garantire che una volta che l'oggetto è stato completamente costruito, quel campo non può essere puntato su un nuovo valore.

Tuttavia, "sola lettura" è molto diverso dagli altri tipi di semantica di sola lettura perché è imposto in fase di esecuzione dal CLR. La parola chiave readonly viene compilata fino a .initonly che è verificabile dal CLR.

Il vero vantaggio di questa parola chiave è generare strutture di dati immutabili. Le strutture di dati immutabili per definizione non possono essere modificate una volta costruite. Questo rende molto facile ragionare sul comportamento di una struttura in fase di esecuzione. Ad esempio, non c'è pericolo di passare una struttura immutabile a un'altra porzione casuale di codice. Non possono mai cambiarlo in modo da poter programmare in modo affidabile contro quella struttura.

Ecco una buona voce su uno dei vantaggi dell'immutabilità: il threading

Non ci sono evidenti benefici in termini di prestazioni nell'uso readonly, almeno nessuno di quelli che abbia mai visto menzionato da nessuna parte. È solo per fare esattamente come suggerisci, per impedire la modifica una volta che è stata inizializzata.

Quindi è utile in quanto ti aiuta a scrivere codice più robusto, più leggibile. Il vero vantaggio di cose come questa viene quando lavori in gruppo o per manutenzione. Dichiarare qualcosa come readonlyè come mettere un contratto per l'uso di quella variabile nel codice. Pensala come aggiungere documentazione allo stesso modo di altre parole chiave come internalo private, stai dicendo "questa variabile non deve essere modificata dopo l'inizializzazione" e inoltre la stai applicando .

Quindi, se crei una classe e contrassegni alcune variabili membro in readonlybase alla progettazione, impedisci a te stesso o ad un altro membro del team di fare un errore in seguito quando si espandono o modificano la tua classe. Secondo me, questo è un vantaggio che vale la pena avere (a scapito della complessità linguistica aggiuntiva come fa doofledorfer nei commenti).

Per dirla in termini molto pratici:

Se usi una const in dll A e dll B fa riferimento a quella const, il valore di quella const verrà compilato in dll B. Se ridistribuisci dll A con un nuovo valore per quella const, la dll B continuerà a utilizzare il valore originale.

Se si utilizza un readonly nei riferimenti dll A e dll B di sola lettura, quello di sola lettura verrà sempre cercato in fase di esecuzione. Ciò significa che se ridistribuisci la dll A con un nuovo valore per quello di sola lettura, la dll B utilizzerà quel nuovo valore.

Esiste un potenziale caso in cui il compilatore può eseguire un'ottimizzazione delle prestazioni in base alla presenza della parola chiave sola lettura.

Questo vale solo se il campo di sola lettura è anche contrassegnato come statico . In tal caso, il compilatore JIT può presumere che questo campo statico non cambierà mai. Il compilatore JIT può tenerne conto durante la compilazione dei metodi della classe.

Esempio tipico: la tua classe potrebbe avere un campo IsDebugLoggingEnabled di sola lettura che viene inizializzato nel costruttore (ad esempio basato su un file di configurazione). Una volta compilati i metodi effettivi JIT, il compilatore può inserire intere parti del codice quando la registrazione di debug non è abilitata.

Non ho verificato se questa ottimizzazione è effettivamente implementata nella versione corrente del compilatore JIT, quindi questa è solo una speculazione.

Ricorda che si applica in sola lettura al valore stesso, quindi se si utilizza un tipo di riferimento in sola lettura protegge solo il riferimento dalla modifica. Lo stato dell'istanza non è protetto da sola lettura.

Non dimenticare che esiste una soluzione alternativa per readonlyimpostare i campi all'esterno di qualsiasi costruttore utilizzando outparams.

Un po 'disordinato ma:

private readonly int _someNumber;
private readonly string _someText;

public MyClass(int someNumber) : this(data, null)
{ }

public MyClass(int someNumber, string someText)
{
    Initialise(out _someNumber, someNumber, out _someText, someText);
}

private void Initialise(out int _someNumber, int someNumber, out string _someText, string someText)
{
    //some logic
}

Ulteriori discussioni qui: http://www.adamjamesnaylor.com/2013/01/23/Setting-Readonly-Fields-From-Chained-Constructors.aspx

Sorprendentemente, in sola lettura può effettivamente portare a un codice più lento, come Jon Skeet ha scoperto durante il test della sua libreria Noda Time. In questo caso, un test eseguito in 20 secondi ha richiesto solo 4 secondi dopo la rimozione di sola lettura.

https://codeblog.jonskeet.uk/2014/07/16/micro-optimization-the-surprising-inefficiency-of-readonly-fields/

Se hai un valore pre-definito o pre-calcolato che deve rimanere lo stesso per tutto il programma, allora dovresti usare costante ma se hai un valore che deve essere fornito in fase di esecuzione ma una volta assegnato dovrebbe rimanere lo stesso per tutto il programma, dovresti usare sola lettura. ad esempio, se è necessario assegnare l'ora di inizio del programma o se si deve memorizzare un valore fornito dall'utente all'inizializzazione dell'oggetto e si deve limitarlo da ulteriori modifiche che è necessario utilizzare in sola lettura.

Aggiunta di un aspetto di base per rispondere a questa domanda:

Le proprietà possono essere espresse in sola lettura tralasciando l' setoperatore. Quindi nella maggior parte dei casi non sarà necessario aggiungere la readonlyparola chiave alle proprietà:

public int Foo { get; }  // a readonly property

Al contrario, i campi richiedono la readonlyparola chiave per ottenere un effetto simile:

public readonly int Foo; // a readonly field

Quindi, uno dei vantaggi della marcatura di un campo readonlypuò essere quello di raggiungere un livello di protezione dalla scrittura simile a una proprietà senza setoperatore - senza dover cambiare il campo in una proprietà, se per qualsiasi motivo, ciò è desiderato.

Fare attenzione con array di sola lettura privati. Se questi vengono esposti a un client come oggetto (potresti farlo per l'interoperabilità COM come ho fatto io) il client può manipolare i valori dell'array. Utilizzare il metodo Clone () quando si restituisce un array come oggetto.

Ci può essere un vantaggio in termini di prestazioni in WPF, in quanto elimina la necessità di costose DependencyProperties. Questo può essere particolarmente utile con le raccolte

Un'altra parte interessante dell'uso della marcatura di sola lettura può essere la protezione del campo dall'inizializzazione in singleton.

ad esempio nel codice di csharpindepth :

public sealed class Singleton
{
    private static readonly Lazy<Singleton> lazy =
        new Lazy<Singleton>(() => new Singleton());

    public static Singleton Instance { get { return lazy.Value; } }

    private Singleton()
    {
    }
}

svolge solo un piccolo ruolo di protezione del campo Singleton dall'inizializzazione due volte. Un altro dettaglio è che per lo scenario menzionato non è possibile utilizzare const perché const forza la creazione durante la compilazione, ma singleton esegue la creazione in fase di esecuzione.

readonlypuò essere inizializzato alla dichiarazione o ottenere il suo valore solo dal costruttore. Diversamente const, deve essere inizializzato e dichiarato allo stesso tempo. readonly ha tutto const , oltre all'inizializzazione del costruttore

codice https://repl.it/HvRU/1

using System;

class MainClass {
    public static void Main (string[] args) {

        Console.WriteLine(new Test().c);
        Console.WriteLine(new Test("Constructor").c);
        Console.WriteLine(new Test().ChangeC()); //Error A readonly field 
        // `MainClass.Test.c' cannot be assigned to (except in a constructor or a 
        // variable initializer)
    }


    public class Test {
        public readonly string c = "Hello World";
        public Test() {

        }

        public Test(string val) {
          c = val;
        }

        public string ChangeC() {
            c = "Method";
            return c ;
        }
    }
}