¿Por qué la clase Singleton debe sellarse?

Question

Quiero saber por qué una clase singleton debe ser sellada. Si le damos al constructor privacidad, podemos evitar que la clase se derive ¿verdad? A continuación, pegaré algunas líneas de MSDN. Por favor, dame un poco de color en él ...

En esta estrategia, la instancia se crea la primera vez que se hace referencia a cualquier miembro de la clase. El tiempo de ejecución del lenguaje común se ocupa de la inicialización de la variable. La clase es marcada sellada para evitar la derivación, que podría agregar instancias. Para una discusión sobre los pros y los contras de marcar una clase sellada, vea [Sells03]. Además, la variable está marcada de solo lectura, lo que significa que solo se puede asignar durante la inicialización estática (que se muestra aquí) o en un constructor de clase.

http://msdn.microsoft.com/en-us/library/ff650316.aspx

Answer 1

Esta es una especie de pautas de diseño que, obviamente, que puede seguir o no. Esto solo marca sus intenciones de diseño, como en el caso de una clase base que lo marque como abstract para evitar posibles problemas en el futuro.

Answer 2

La palabra clave sealed significa que no se puede heredar la clase. Declarar constructores privados significa que no se pueden crear instancias de la clase.

Estas no son la misma cosa. Puede tener una clase base con un constructor privado, pero aún heredar de esa clase base, definir algunos constructores públicos y crear una instancia de esa clase base.

Recuerde que los constructores no son heredados (por lo que la clase derivada no tendrá todos los constructores privados solo porque la clase base lo hace), y que las clases derivadas siempre llaman primero a los constructores de la clase base. Marcar la clase sealed evita que alguien trabaje trivialmente en torno a su clase singleton cuidadosamente construida porque evita que alguien herede de la clase.

Answer 3

Si le estamos dando al constructor como privado podemos evitar que la clase sea derivada, ¿verdad?

No bastante:

public class NotReallySingleton 
{ 
    private NotReallySingleton() {} 

    public class CursesFoiledAgain : NotReallySingleton 
    { 
    } 
} 

... 

NotReallySingleton x = new CursesFoiledAgain(); 
NotReallySingleton y = new CursesFoiledAgain(); 

Esto funciona porque private el acceso está limitado al texto del programa del tipo, incluyendo tipos anidados. Entonces CursesFoiledAgain tiene acceso al constructor privado de NotReallySingleton.

Pero incluso dejando esto a un lado, si su intención es que nadie puede derivar de la clase, ¿por qué no quiere señalar que la intención de la mayor claridad posible, a través de sealed?