Extracto del código de Singleton, una pregunta de la entrevista

Question

Tuve otra pregunta de la entrevista. Pensé que esto era una tontería, pero tal vez hay algo que me falta. La pregunta preguntó qué patrón de GoF es esto (respuesta: singleton) y, si hay algún problema, cómo los resuelvo.

No veo ningún problema. Mencioné que esto nunca se libera y espero que de este patrón. Eso es todo lo que dije. ¿Me estoy perdiendo de algo?

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

Answer 1

Seguridad de subprocesos: pueden crearse múltiples instancias si se llama a GetInstance() desde hilos de la competencia.

Answer 2

Tiene una condición de carrera potencial en código multiproceso. Dos subprocesos podrían superar la comprobación nula antes de que el constructor del otro subproceso se complete, de modo que ambos puedan terminar construyendo la clase.

Answer 3

Existe un problema potencial con esto si tiene una aplicación multiproceso. Esto puede hacer que se construya más de una instancia si se solicitan dos hilos al mismo tiempo.

Echaré un vistazo a esta página en Singletons in C#. Muestra el problema en detalle, así como mejores opciones.

Answer 4

Ver: An obvious singleton implementation for .NET?

hay múltiples preocupaciones que desee considerar cuando se implementa un patrón Singleton.

• ¿Qué pasa cuando múltiples llamadas de solicitud de el singleton de múltiples hilos. Simplemente debería funcionar.
• Cuando se llama al ejemplo de Singleton . Es posible que desee diferirlo para que ocurra en la primera llamada que solicite el singleton, es posible que desee primero crear una instancia en otro momento.
• ¿Debería la gente poder heredar de su clase singleton? ¿Cuál debería ser el comportamiento?
• Debería ser posible cambiar su instancia singleton a una instancia diferente después de que se haya instanciado el singleton. Responder afirmativamente a esto viola el patrón de singleton, por lo que, en general, el campo que contiene los singletons debe ser , solo.
• Diseño de API, si utiliza una propiedad o método para devolver la instancia de Singleton.
• Algunos personas dicen singletons evil. Deberías incluso estar considerándolo en primer lugar. Esto ha sido discutido muy a menudo un buen punto de partida es http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx

El siguiente es un buen patrón de propósito general que podría seguir. Su hilo seguro, sellado, usa propiedades y difiere instansiates el 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

El código no es seguro para subprocesos.Para que sea lo que necesita para hacer esto:

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

Ésta es la forma más eficiente de la carga de la instancia con pereza, ya que sólo molesta para bloquear (puede ser caro) cuando se sospecha la instancia no se creará una instancia para la próxima llamada. Revisar nuevamente una vez en la cerradura asegura que solo se creará una instancia una vez.

Answer 6

¿Cuál es la solución?

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

Answer 7

Otros mencionaron la seguridad de la rosca. También está el hecho de que olvidaron marcarlo como sealed, por lo que podría heredarlo y crear varias instancias de esa manera.

Answer 8

No trabaje en esa empresa. El patrón singleton no es un patrón frecuentemente utilizado y su aplicabilidad en un sistema OO puro es cuestionable. Deshacer un patrón singleton es un gran problema si alguna vez tiene que volver a convertirlo en un objeto normalmente construido.

Answer 9

Falta seguridad de hilo, this page lo explica muy bien.