c# - pattern - Singleton por Jon Skeet clarificación

singleton c# unity

Question

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

Deseo implementar el patrón Singleton de Jon Skeet en mi aplicación actual en C #.

Tengo dos dudas sobre el código.

1. ¿Cómo es posible acceder a la clase externa dentro de la clase anidada? quiero decir

   internal static readonly Singleton instance = new Singleton();

   ¿Se llama cierre algo?

2. No puedo entender este comentario.

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

   ¿Qué nos sugiere este comentario?

Answer 1

1. No, esto no tiene nada que ver con los cierres. Una clase anidada tiene acceso a los miembros privados de su clase externa, incluido el constructor privado aquí.

2. Lee mi artículo en el campo anterior . Puede o no desear el constructor estático no operativo: depende de la pereza que le garantice la necesidad. Debe tener en cuenta que .NET 4 cambia un poco la semántica de inicialización de tipo real (aún dentro de la especificación, pero más perezosa que antes).

¿ Realmente necesitas este patrón sin embargo? ¿Está seguro de que no puede salirse con la suya?

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

Answer 2

Respecto a la pregunta (1): La respuesta de Jon es correcta, ya que marca implícitamente que la clase ''Anidada'' es privada al no hacerlo pública o interna :-). También podrías hacerlo explícitamente agregando ''privado'':

 private class Nested

Respecto a la pregunta (2): básicamente, lo que la publicación acerca de la inicialización de tipo BeforeInitfield y Type le dice es que si no tiene un constructor estático, el Runtime puede iniciarlo en cualquier momento (pero antes de usarlo). Si tiene un constructor estático, su código en el constructor estático podría inicializar los campos, lo que significa que el tiempo de ejecución solo puede inicializar el campo cuando solicita el tipo.

Entonces, si no desea que el tiempo de ejecución inicialice los campos ''proactivamente'' antes de usarlos, agregue un constructor estático.

De cualquier manera, si está implementando singletons, o bien desea que se inicie lo más perezoso posible y no cuando el tiempo de ejecución cree que debería inicializar su variable, o probablemente no le importe. Por tu pregunta, supongo que los quieres lo más tarde posible.

Eso nos lleva a la publicación de Jon sobre singleton , que es el tema subyacente de esta pregunta. Ah y las dudas :-)

Me gustaría señalar que su singleton # 3, que marcó "incorrecto", es realmente correcto (porque el bloqueo implica automáticamente una barrera de memoria en la salida ). También debe ser más rápido que singleton # 2 cuando usa la instancia más de una vez (que es más o menos el punto de un singleton :-)). Por lo tanto, si realmente necesita una implementación perezosa de singleton, es probable que vaya por esa, por las simples razones de que (1) es muy claro para todos los que lean su código lo que está pasando y (2) saben qué sucederá con excepciones.

En caso de que se lo pregunte: nunca usaría singleton # 6 porque puede llevar a puntos muertos y comportamientos inesperados con excepciones. Para obtener más información, consulte: el modo de bloqueo lento , específicamente ExecutionAndPublication.