Recientemente he estado leyendo varios artículos y blogs que hablan sobre el patrón singleton. Su objetivo es asegurar que, dada una clase concreta, se dispone de una única instancia de ella en una aplicación.

La referencia principal sobre patrones es el libro “Design Patterns: Elements of Reusable Object-Oriented Software” donde se explica cómo funciona de manera genérica.

La gente sigue muchas veces al pie de la letra el libro y eso puede hacer que no se tengan en cuenta detalles del lenguaje o la plataforma que se esté utilizando y se llegue a situaciones que puedan complicarse, generándose errores en el código difíciles de detectar.

En el caso de .NET, hay una discusión bastante a fondo sobre el tema en el artículo “Exploring the Singleton Design Pattern”, donde se tienen en cuenta las ventajas del entorno concreto, evitando así muchos de los problemas que pueden darse si se intenta hacer una implementación directa según se copia el código del libro.

Teniendo esto en mente, en C# el código para un Singleton es bastante sencillo:

public class MiClase
{
 private MiClase() {}

 public static readonly MiClase Instance = new MiClase();

 public void HazAlgo()
 {
  …
 }
}

Como se ve, la implementación básica consta de 2 líneas de código, un constructor privado y una variable estática (Instance en este caso) que da acceso a la instancia única. Para entender los detalles de por qué esto funciona así, leer con detalle el artículo mencionado arriba.
A la instancia (única) de la clase se accederá desde el código cliente de la siguiente forma:

…
MiClase.Instance.HazAlgo();
…

Bajo mi punto de vista, esto queda muy limpio y sencillo de usar.

Los usos que se le pueden dar al Singleton son múltiples, como por ejemplo clases que almacenan información de configuración de la aplicación, clases para hacer logs, etc. Eso sí, ojo con su uso en aplicaciones web ya que podéis encontraros con problemas de concurrencia si no se tiene cuidado.