Estratto di codice di Singleton, un'interrogazione-domanda

Question

Ho avuto un'altra domanda di intervista. Pensavo fosse sciocco, ma forse c'è qualcosa che mi manca. La domanda ha chiesto quale pattern GoF sia (risposta: singleton) e, se ci sono problemi, come li risolvo.

Non vedo alcun problema. Ho detto che questo non è mai stato liberato e che mi aspetto da questo schema. Questo è tutto ciò che ho detto. Mi sto perdendo qualcosa?

public class Class1 
{ 
    private static Class1 oInstance = null; 
    private Class1() { } 
    public static Class1 GetInstance() 
    { 
     if (oInstance == null) 
     { 
      oInstance = new Class1(); 
     } 
     return oInstance ; 
    } 
} 

Answer 1

Sicurezza thread: è possibile creare più istanze se GetInstance() viene chiamato da thread concorrenti.

Answer 2

Hai una potenziale condizione di competizione nel codice multithread. Due thread potrebbero superare il controllo Null prima che il costruttore sull'altro thread sia completato, in modo che entrambi possano finire per costruire la classe.

Answer 3

C'è un potenziale problema con questo se si dispone di un'applicazione multithread. Ciò può causare la creazione di più di un'istanza se due thread richiedono allo stesso tempo.

Darei un'occhiata a questa pagina su Singletons in C#. Mostra il problema in dettaglio, oltre a opzioni migliori.

Answer 4

Vedi: An obvious singleton implementation for .NET?

ci sono più le preoccupazioni che si desidera prendere in considerazione in sede di attuazione di un pattern Singleton.

• Cosa accade quando più chiamanti richiesta il singoletto da più thread. Dovrebbe funzionare.
• Quando è chiamato il costruttore dell'istanza Singleton. Si consiglia di posticiparlo in modo che avvenga alla prima chiamata che richiede il singleton, potreste volerlo prima istanziare in un altro momento.
• Le persone possono essere in grado di ereditare dalla classe singleton? Quale dovrebbe essere il comportamento?
• Dovrebbe essere possibile passare l'istanza singleton a un'istanza diversa dopo l'istanza del singleton. Rispondendo sì a questo viola il modello singleton, quindi in generale i single singletons di campo dovrebbero essere in sola lettura.
• Progettazione API, se si utilizza una proprietà o un metodo per restituire l'istanza Singleton.
• Alcuni persone dicono singleton sono cattivi. Dovresti anche considerarlo in primo luogo. Questo è stato discusso abbastanza spesso un buon punto di partenza è http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx

Quanto segue è un buon schema generale che potreste seguire. Il suo filo sicuro, sigillato, usa le proprietà e rinvia instrada il singleton.

public sealed class Singleton 
{ 
    static class SingletonCreator 
    { 
     // This may seem odd: read about this at: http://www.yoda.arachsys.com/csharp/beforefieldinit.html 
     static SingletonCreator() {} 
     internal static readonly Singleton Instance = new Singleton(); 
    } 

    public static Singleton Instance 
    { 
     get { return SingletonCreator.Instance; } 
    } 
} 

Answer 5

Il codice non è thread-safe.Per fare in modo che devi fare questo:

public class Class1 
{ 
    private static Class1 oInstance = null; 
    private Class1() { } 
    public static Class1 GetInstance() 
    { 
     if (oInstance == null) 
     { 
      lock(typeof(Class1)) 
      { 
       if (oInstance == null) 
       { 
        oInstance = new Class1(); 
       } 
      } 
     } 
     return oInstance ; 
    } 
} 

Questo è il modo più efficiente di pigramente caricare l'istanza come dà fastidio solo per bloccare (può essere costoso) quando si sospetta non sarà istanziato l'istanza per la prossima chiamata. Il controllo di nuovo una volta nella serratura assicura che verrà istanziato una sola volta.

Answer 6

quindi la soluzione è la seguente?

public class Class1 
{ 
    private static Class1 oInstance = new Class1(); 
    private Class1() { } 
    public static Class1 GetInstance() 
    { 
     return oInstance ; 
    } 
} 

Answer 7

Altri citati sicurezza del filo. C'è anche il fatto che si sono dimenticati di contrassegnarlo come sealed, quindi si potrebbe ereditare da esso e creare più istanze in questo modo.

Answer 8

Non lavorare in quell'azienda. Il modello singleton non è uno schema usato frequentemente e la sua applicabilità in un puro sistema OO è discutibile. Annullare un modello singleton è un grosso problema se si ha la necessità di riattivarlo in un oggetto costruito normalmente.

Answer 9

Manca la sicurezza del thread, this page lo spiega molto bene.