design patterns - patterns - ¿Por qué usar singleton en lugar de clase estática?

singleton pattern javascript

Question

¿Cuándo un singleton sería realmente más fácil o mejor que una clase estática? Me parece que crear un singleton es un esfuerzo extra que en realidad no es necesario, pero estoy seguro de que hay una buena razón. De lo contrario, no serían utilizados, obviamente.

Answer 1

1. Un Singleton puede implementar interfaces, heredar de otras clases
2. Un Singleton se puede inicializar de forma lenta o asíncrona y cargarse automáticamente con .NET Framework CLR (Common Language Runtime) cuando se carga el programa o el espacio de nombres que contiene la clase. Mientras que una clase estática generalmente se inicializa cuando se carga por primera vez y dará lugar a posibles problemas de cargador de clases.
3. La clase Singleton sigue los Principios Orientados a Objetos
4. Objetos Singleton almacenados en el montón mientras la clase estática se almacena en la pila.
5. Los objetos Singleton pueden tener constructor mientras que la clase estática no.
6. Los objetos Singleton pueden eliminar pero no la clase estática
7. Singleton Objects puede clonar pero no con clase estática

Answer 2

Aunque en mi humilde opinión, el patrón singleton es un patrón bastante usado en exceso, a veces ofrece beneficios, tales como:

• La capacidad de usar diferentes tipos de objetos (que heredan de la misma base) que la instancia (piense en los proveedores de datos donde uno usa el sistema de archivos y uno en una base de datos SQL, por ejemplo)
• Serializabilidad. No he usado un marco que pueda serializar automáticamente clases estáticas.
• Usando menos campos estáticos. Para algunas personas esto es más una característica estética, pero en algunos casos tiene beneficios prácticos.

Answer 3

En muchos idiomas, las clases estáticas carecen de características útiles, como la herencia (y el polimorfismo en general).

( No es que defienda los singleton ).

Answer 4

Los singleton conservan el enfoque de clase convencional y no requieren que use la palabra clave estática en todas partes. Pueden ser más exigentes de implementar al principio, pero simplificarán en gran medida la arquitectura de su programa. A diferencia de las clases estáticas, podemos usar singletons como parámetros u objetos.

Además, puede usar singletons con interfaces como cualquier otra clase.

Answer 5

Los singletons a menudo se prefieren a las variables globales porque:

• No contaminan el espacio de nombres global (o, en los idiomas con espacios de nombres, su espacio de nombres que lo contiene) con variables innecesarias.
• Permiten asignación e inicialización diferida, mientras que las variables globales en muchos idiomas siempre consumirán recursos.

Source

EDITAR:

Un buen uso del singleton es, cuando se combina con el método de fábrica, se puede utilizar para crear el patrón Flyweight . Esto es cuando crea un nuevo objeto, Factory (en lugar de crear un nuevo objeto) comprueba primero para ver que una sola parte de ese objeto ya está hecha, si lo está, simplemente devuelve ese objeto; si no, crea un nuevo singleton. y lo devuelve, haciendo un seguimiento de los singletons que crea. Los pesos flotantes funcionan debido a la inmutabilidad del singleton.

Answer 6

Singletons siempre me pareció un poco redundante. Prefiero clases estáticas, y si necesito un comportamiento diferente, lo combino con una inyección de dependencia y un proveedor ... No sé qué patrón es, o si tiene un nombre, pero por lo general es más o menos así:

public interface IFooProvider {
  Bar FooBar();
}

public static class Foo {
  public static readonly IFooProvider FooProvider { get; set; }
  public Bar FooBar() { return FooProvider.FooBar(); }
}

Luego solo me aseguro de configurar el proveedor en algún lugar de mi método init. Es fácil agregar una inicialización lenta si lo desea estableciendo el proveedor predeterminado en la inicialización de la clase. Lo mejor de todo es que le permite cambiar el comportamiento sin perder la estética del uso de clases estáticas.

Answer 7

Una buena razón para preferir un singleton a una clase estática (suponiendo que no haya mejores patrones a su disposición;)), es intercambiar una instancia de singleton con otra.

Por ejemplo, si tengo una clase de registro como esta:

public static class Logger {
    public static void Log(string s) { ... }
}

public class Client {
    public void DoSomething() {
        Logger.Log("DoSomething called");
    }
}

Funciona muy bien, pero ¿qué ocurre si Logger escribe cosas en una base de datos o escribe resultados en la consola? Si está escribiendo pruebas, probablemente no quiera todos esos efectos secundarios, pero como el método de registro es estático, no puede hacer nada excepto.

Ok, entonces quiero intercambiar en caliente mi método de registro para probar. ¡Ve a buscar el gadget singleton!

public class Logger {
    private static Logger _instance;
    public static Logger Instance
    {
        get
        {
            if (_instance == null)
                _instance = new Logger();
            return _instance;
        }
        set { _instance = value; }
    }
    protected Logger() { }
    public virtual void Log(string s) { ... }
}

public class Client {
    public void DoSomething() {
        Logger.Instance.Log("DoSomething called");
    }
}

Por lo tanto, puede definir un TestLogger : Logger con un método de Log vacío, luego establecer una instancia de su registrador de prueba en la instancia de singleton para las pruebas. ¡Presto! Puede enrutar su implementación de registrador para pruebas o producción sin afectar el código del cliente.