Ir al contenido principal

El patrón Singleton en C#

Patrones de Diseño

Los patrones de diseño, son soluciones reutilizables para problemas comunes que enfrentan los desarrolladores durante el diseño de sistemas de software. Ayudan a estructurar el código de manera eficiente y escalable, proporcionando guías para resolver problemas específicos dentro de cierto contexto. Entre los patrones más conocidos en .NET se encuentran patrones como Fachada, que organiza componentes o el Singleton, que se aplica directamente a una clase para el control de instancias, entre otros.

Estos patrones, generalmente se clasifican en tres tipos principales:

  1. Patrones creacionales
  2. Patrones Estructurales
  3. Patrones de Comportamiento
Singleton entra en la categoría de patrón creacional y estos se enfocan en cómo se crean los objetos de un componente.

¿Qué es el Patrón Singleton?

El patrón Singleton asegura que una clase tenga una sola instancia accesible globalmente y proporciona un punto de acceso centralizado a dicha instancia. Este patrón es útil en situaciones donde una única instancia debe coordinar acciones en todo el sistema, como un manejador de configuración o un administrador de sesiones. 

A diferencia de patrones como Fábrica o Fachada, que operan a nivel de componentes, el Singleton se implementa directamente en una clase. Esto lo hace ideal para aplicaciones que necesitan controlar estrictamente la cantidad de instancias creadas, ya sea una o un conjunto de ellas.

Cómo implementar el patrón Singleton en C#

La implementación del patrón Singleton en C# implica realizar tres modificaciones clave en la clase:

1. Almacenar las instancias de la clase

Se crea un atributo privado y estático para almacenar la instancia de la clase. Si es un Singleton puro, este atributo almacena una única instancia; si es un Singleton "variado", puede almacenar un conjunto de instancias.

 private static MiClase _instancia;
  • static: porque la que guarda la instancia es la propia clase y se comparte a nivel de la misma.
  • private: porque solo la clase debe tener control sobre la instancia.
2. Constructor privado

Se declara un constructor con acceso privado para evitar que se creen instancias fuera de la clase:
private MiClase() { }

Esto impide que alguien utilice new MiClase() directamente desde fuera.

3. Proporcionar un mecanismo de acceso

Se añade método o una propiedad de solo lectura (es decir que tiene solo get, no set). Este mecanismo asegura que, si no existe la instancia, se cree y se retorne; en caso contrario, se devuelve la instancia existente.
public static MiClase _instancia
{
    get
    {
        if(_instancia == null)
        {
            _instancia = new MiClase();
        }
        // retorno la instancia
        return _instencia; 
    }
}

Palabra clave que tenés que conocer: Lazy Initialization. La instancia se crea solo cuando se solicita por primera vez, lo cual es sumamente beneficioso para nosotros ya que optimizamos el uso de recursos.

Con estos cambios combinados en nuestra clase de servicio o trabajo nos quedaría algo así:
private class MiClase
{
    // Atributo privado/estático
    private static MiClase _instancia;

    // Constructor privado
    private MiClase() { }

    // Propiedad estática para acceder a la instancia
    public static MiClase _instancia
    {
        get
        {
            if(_instancia == null)
            {
                _instancia = new MiClase();
            }
            // retorno la instancia
            return _instencia; 
        }
    }
}

Ventajas del Patrón Singleton

  1. Control de instancias: Garantiza que solo haya una instancia (o un conjunto limitado) de la clase.
  2. Acceso global: Proporciona un único punto de acceso a la instancia.
  3. Optimización de recursos: Especialmente útil en clases que requieren configuraciones costosas o acceso exclusivo a recursos como memoria. 

¿Cuándo usar el Patrón Singleton?

El Singleton es ideal en los siguientes escenarios:
  • Cuando una clase debe coordinar recursos o servicios compartidos, como un administrador de configuración o conexión a base de datos.
  • Cuando una única instancia debe mantener el estado en toda la aplicación, como un registro de logs.
En conclusión, podemos decir que el patrón Singleton es una solución para problemas relacionados con el control de instancias en una clase. 

Aunque su implementación es sencilla, su uso debe evaluarse cuidadosamente, ya que un mal uso puede introducir dependencias globales que dificultan las pruebas unitarias y el mantenimiento del código. Utilizado de manera adecuada, el Singleton es una herramienta poderosa para garantizar un diseño limpio y funcional para las aplicaciones.

Otros artículos

Principio de Sustitución de Liskov (LSP) – SOLID explicado con ejemplos

¿Qué es el Principio de Sustitución de Liskov? Imaginá que tenés un control remoto universal diseñado para funcionar con cualquier televisor. Si un nuevo modelo de TV no responde a los mismos comandos, el control deja de ser útil. El Principio de Sustitución de Liskov es como una garantía de que cualquier 'televisor' (o clase derivada) va a funcionar correctamente con el 'control remoto' (o clase base). El Principio de Sustitución de Liskov ( LSP ) es el tercer principio de SOLID , representado por la letra L y establece que: Los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin afectar el comportamiento correcto del programa. En otras palabras, si una clase hija hereda de una clase padre, cualquier instancia de la clase hija debería poder usarse en lugar de una instancia de la clase padre sin alterar la funcionalidad esperada. ¿Quién es Bárbara Liskov? Bárbara Liskov es una destacada científi...

Open/Closed Principle (OCP) – SOLID explicado con ejemplos

Continuando con el repaso de los principios de S.O.L.I.D. que inició en el hilo anterior - si no lo viste hacé click acá  Principio de Responsabilidad Única (SRP) - vamos a ver el segundo en orden de aparición: Principio de Abierto/Cerrado (OCP por sus siglas en inglés). Definición Formal El principio OCP (Open/Closed Principle) establece que el código de una clase o un módulo debe estar abierto para la extensión, pero cerrado para la modificación. Esto significa que no se deben realizar cambios en el código existente cuando se requiere alterar alguna funcionalidad. En lugar de modificar el código existente, se debe crear una nueva implementación que extienda la funcionalidad. La única excepción a esto son los arreglos de bugs, donde está permitido modificar el código existente. Si se desea introducir una nueva funcionalidad, como la ordenación en un método existente, en lugar de modificar el código, se crearía una nueva implementación q...

Evolución de ASP .NET: de Web Forms a .NET Core

La historia de ASP .NET  (Active Server Pages) se remonta a 1996, cuando Microsoft lanzó la primera versión de ASP como una solución para desarrollar páginas web dinámicas.  Esta tecnología fue pionera en su momento, permitiendo a los desarrolladores combinar HTML, scripts y componentes para crear aplicaciones web funcionales. Sin embargo, con el tiempo, las crecientes demandas del desarrollo web moderno hicieron evidente la necesidad de una evolución tecnológica.  Fue en 2002 cuando esta evolución dio un gran salto con la llegada de ASP .NET  Web Forms , marcando el inicio oficial de la nueva era de ASP .NET. Diseñada para facilitar la transición de los desarrolladores de aplicaciones de escritorio al mundo web, Web Forms adoptó un enfoque que emulaba la programación de escritorio e introdujo conceptos como el ViewState y eventos en el servidor . Aunque ASP .NET Web Forms trajo avances importantes, también mostró sus limitaciones con el ...

Principio de Responsabilidad Única (SRP) – SOLID explicado con ejemplos

Introducción a S.O.L.I.D En esta entrada, intentaremos abordar un nuevo ciclo de conceptos que tienen que ver sobre los principios SOLID , que son fundamentales en la programación orientada a objetos o POO . Estos principios fueron formulados, en principio, por Robert C. Martin , también conocido como " Uncle Bob ", con el objetivo de mejorar la mantenibilidad y escalabilidad del código de software. SOLID es un acrónimo que representa cinco principios de diseño: Single Responsibility Principle (SRP) – Principio de Responsabilidad Única Open/Closed Principle (OCP) – Principio de Abierto/Cerrado Liskov Substitution Principle (LSP ) – Principio de Sustitución de Liskov Interface Segregation Principle (ISP) – Principio de Segregación de Interfaces Dependency Inversion Principle (DIP) – Principio de Inversión de Dependencias Estos principios nos ayudan a crear software más ...

Roadmap para Desarrolladores Backend en .NET en 2025

El mundo del desarrollo backend está en constante evolución, y mantenerse actualizado con las mejores prácticas y tecnologías es clave para seguir siendo competitivo en el mercado. Si estás buscando una guía clara y estructurada para mejorar tus habilidades en . NET backend , el sitio roadmap.sh ofrece un excelente punto de partida. Para esta entrada vamos a explorar lo siguiente: ¿Qué es roadmap.sh y por qué es relevante? El roadmap backend para .NET en 2025 Tecnologías y habilidades esenciales para backend a considerar ¿Qué es roadmap.sh y quién lo creó? roadmap.sh es una plataforma ampliamente reconocida dentro de la comunidad de desarrolladores. Fue creada por Kamran Ahmed, un Google Developer Expert y contribuidor en múltiples proyectos de código abierto. Desde su lanzamiento, la plataforma ha crecido exponencialmente, acumulando más de 300,000 estrellas en GitHub y una comunidad activa de...

Principio de Inversión de Dependencia (DIP) – SOLID explicado con ejemplos

Estamos cerrando este ciclo de definiciones para SOLID , y en esta entrada vamos a dar un vistazo al último principio de la lista: DIP o Dependency Inversion Principle . El Principio de Inversión de Dependencia (DIP) establece que: Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones. El Problema de la Dependencia Directa Imaginate que estás construyendo una aplicación que envía notificaciones. Para empezar rápido, decidís crear un controlador que usa directamente un servicio de correo electrónico: public class NotificationController { private EmailNotificationService _service = new EmailNotificationService (); // Acá tenemos dependencia directa } Al principio, todo parece estar bien. El controlador puede enviar correos sin problema. Pero luego surge un requisito: ta...