Chiarimento Singleton di Jon Skeet

public sealed class Singleton
{
    Singleton() {}

    public static Singleton Instance
    {
        get
        {
            return Nested.instance;
        }
    }

    class Nested
    {
        // Explicit static constructor to tell C# compiler
        // not to mark type as beforefieldinit
        static Nested() {}
        internal static readonly Singleton instance = new Singleton();
    }
}

Vorrei implementare il modello Singleton di Jon Skeet nella mia attuale applicazione in C #.

Ho due dubbi sul codice

1. Come è possibile accedere alla classe esterna all'interno della classe nidificata? intendo

   internal static readonly Singleton instance = new Singleton();

   Qualcosa si chiama chiusura?

2. Non riesco a capire questo commento

   // Explicit static constructor to tell C# compiler
   // not to mark type as beforefieldinit

   cosa ci suggerisce questo commento?

1. No, questo non ha nulla a che fare con le chiusure. Una classe nidificata ha accesso ai membri privati ​​della sua classe esterna, incluso il costruttore privato qui.

2. Leggi il mio articolo su beforefieldinit . Potresti o non vuoi il costruttore statico no-op - dipende da quale pigrizia ti garantisce. È necessario essere consapevoli che .NET 4 cambia le effettive tipo di inizializzazione semantica in qualche modo (ancora all'interno le specifiche, ma più pigri rispetto a prima).

Hai davvero bisogno di questo modello però? Sei sicuro di non riuscire a cavartela con:

public sealed class Singleton
{
    private static readonly Singleton instance = new Singleton();
    public static Singleton Instance { get { return instance; } }

    static Singleton() {}
    private Singleton() {}
}

Per quanto riguarda la domanda (1): la risposta di Jon è corretta, dal momento che segna implicitamente la classe "Annidata" privata non rendendola pubblica o interna :-). Puoi anche farlo esplicitamente aggiungendo "privato":

    private class Nested

Per quanto riguarda la domanda (2): sostanzialmente ciò che ti dice il post su beforeinitfield e l' inizializzazione del tipo è che se non hai un costruttore statico, il runtime può inizializzarlo in qualsiasi momento (ma prima di usarlo). Se si dispone di un costruttore statico, il codice nel costruttore statico potrebbe inizializzare i campi, il che significa che al runtime è consentito inizializzare il campo solo quando si richiede il tipo.

Quindi, se non si desidera che il runtime inizializzi i campi 'in modo proattivo' prima di utilizzarli, aggiungere un costruttore statico.

In entrambi i casi, se stai implementando i singoli punti o vuoi che inizializzi il più pigro possibile e non quando il runtime pensa che dovrebbe inizializzare la tua variabile - o probabilmente non ti interessa. Dalla tua domanda suppongo che li desideri il più tardi possibile.

Ciò porta a incontrare il post di Jon sul tema di Singleton , che è l'IMO il tema alla base di questa domanda. Oh e i dubbi :-)

Vorrei sottolineare che il suo singleton n. 3, che ha contrassegnato come "sbagliato", è in realtà corretto (perché il blocco implica automaticamente una barriera di memoria all'uscita ). Dovrebbe anche essere più veloce di singleton # 2 quando usi l'istanza più di una volta (che è più o meno il punto di un singleton :-)). Quindi, se hai davvero bisogno di un'implementazione pigra di singleton, probabilmente lo farei per quello - per i semplici motivi che (1) è molto chiaro per tutti coloro che leggono il tuo codice cosa sta succedendo e (2) sai cosa accadrà con eccezioni.

Nel caso ti stia chiedendo: non userei mai singleton # 6 perché può facilmente portare a deadlock e comportamenti imprevisti con eccezioni. Per i dettagli, consultare: modalità di blocco di pigro , in particolare ExecutionAndPublication.