Patrón Singleton en TypeScript: Una guía completa

En el desarrollo de software, algunas soluciones son poderosas pero requieren cuidado. El patrón Singleton garantiza que una clase tenga una única instancia y proporciona un punto de acceso global a esa instancia, útil para recursos como gestores de configuración o servicios de logging¹. En esta guía verás cuándo usarlo, cómo implementarlo en TypeScript, sus riesgos, y alternativas modernas con inyección de dependencias.

¿Qué es el patrón Singleton y cuándo es útil?

El patrón Singleton restringe la creación de objetos para que solo exista una instancia durante el ciclo de vida de la aplicación. Esa instancia central actúa como la fuente de verdad para una responsabilidad específica, como configuración o acceso a hardware.

Propósito central y analogía

No se trata solo de impedir nuevas instancias; se trata de centralizar el control. Igual que el Escritor Real gestiona los decretos, un Singleton centraliza un recurso compartido para evitar versiones conflictivas.

Un uso típico es la gestión de conexiones a la base de datos o un pool de conexiones: no quieres que cada componente abra su propia conexión; un único gestor puede repartir las conexiones de forma eficiente.

Patrón Singleton de un vistazo

Casos de uso prácticos

Cuando el recurso es inherentemente único, el Singleton puede ser apropiado:

• Servicios de logging: una única instancia central evita fragmentación de registros.
• Gestión de configuración: una única fuente de ajustes para toda la aplicación.
• Acceso a hardware: una interfaz única a un dispositivo físico evita comandos en conflicto.

Beneficios y desventajas de usar Singletons

El Singleton es directo y útil para ciertos problemas, pero también trae compromisos importantes.

Beneficios

• Punto de acceso global que simplifica llamadas entre módulos.
• Ahorro de recursos mediante inicialización perezosa.
• Evita múltiples instancias conflictivas de recursos costosos.

Desventajas

• Acoplamiento fuerte: las dependencias quedan ocultas y el código puede volverse rígido.
• Estado global mutable: puede causar errores difíciles de reproducir.
• Impacto en las pruebas: el estado persistente complica el aislamiento y el mocking.³

Impacto en las pruebas y el acoplamiento

Los Singletons complican las pruebas unitarias al introducir estado global que puede filtrarse entre pruebas. Por eso muchos equipos prefieren la inyección de dependencias (DI), que hace las dependencias explícitas y fáciles de sustituir en tests³.

Equilibrando los compromisos

Valora conveniencia frente a mantenibilidad. En código legacy, una ruta segura es refactorizar de forma incremental hacia DI, introduciendo interfaces y pasando dependencias desde la raíz de composición.

Usa Singletons con moderación: simplicidad hoy puede significar deuda técnica mañana.

Implementación del patrón Singleton en TypeScript

A continuación, un ejemplo claro y tipado en TypeScript. La clave es un constructor private y un método static que controla la instancia.²

Ejemplo: ConfigManager con tipos seguros

class ConfigManager {
  private static instance: ConfigManager;
  private settings: Map<string, any> = new Map();

  private constructor() {
    console.log('Inicializando ConfigManager...');
    this.settings.set('API_URL', 'https://api.example.com');
    this.settings.set('TIMEOUT', 5000);
  }

  public static getInstance(): ConfigManager {
    if (!ConfigManager.instance) {
      ConfigManager.instance = new ConfigManager();
    }
    return ConfigManager.instance;
  }

  public get(key: string): any {
    return this.settings.get(key);
  }
}

// const config = new ConfigManager(); // Error: el constructor es privado

Este patrón aplica los modificadores de TypeScript para asegurar una instancia única e inicialización perezosa.²

Usando el Singleton en un servicio

class ApiService {
  private apiUrl: string;

  constructor() {
    const config = ConfigManager.getInstance();
    this.apiUrl = config.get('API_URL');
    console.log(`ApiService inicializado con API URL: ${this.apiUrl}`);
  }

  public fetchData(): void {
    console.log(`Consultando ${this.apiUrl}...`);
    // Lógica real de fetch aquí.
  }
}

console.log('Aplicación iniciando...');
const service1 = new ApiService();
service1.fetchData();
const service2 = new ApiService();
console.log('Aplicación finalizada.');

Al ejecutar, verás el mensaje de inicialización de ConfigManager solo una vez, lo que demuestra que ambas instancias usan la misma configuración.

Por qué los Singletons tienen mala fama

Aunque atractivos por su simplicidad, los Singletons ocultan dependencias, introducen estado compartido y complican las pruebas. Cuando una clase accede silenciosamente a una instancia global, esa dependencia debería ser explícita en su constructor para facilitar el razonamiento y el testing.³

Condiciones de carrera y concurrencia

Los Singletons con estado pueden sufrir condiciones de carrera en entornos concurrentes. Por ejemplo, un contador de sesión incrementado por peticiones simultáneas puede producir resultados inconsistentes sin sincronización adecuada.

Pruebas frágiles

El estado persistente de un Singleton puede filtrarse entre pruebas y hacer que el orden de ejecución influya en los resultados. La inyección de dependencias permite pasar dobles (mocks) fácilmente y aísla cada prueba. Para más sobre testing y patrones ver: Testing en TypeScript y Buenas prácticas de DI.

Alternativas modernas al Singleton

La inyección de dependencias (DI) es la alternativa preferida para gestionar recursos compartidos. DI hace las dependencias explícitas y mejora la modularidad y la testabilidad.

Inyección de dependencias frente a Singletons

En lugar de que ApiService llame a ConfigManager.getInstance(), acepta un gestor de configuración por constructor:

interface IConfigManager {
  get(key: string): any;
}

class ApiService {
  private apiUrl: string;

  constructor(config: IConfigManager) {
    this.apiUrl = config.get('API_URL');
  }
}

Ahora ApiService depende del contrato IConfigManager. En tests puedes pasar un mock, y el acoplamiento queda explícito.

Algunos frameworks de TypeScript incluyen contenedores DI integrados (por ejemplo, NestJS) o permiten usar bibliotecas como InversifyJS para gestionar ciclos de vida y alcances de objetos⁴⁵.

Contenedores IoC

Un contenedor de Inversión de Control permite decidir si una dependencia es transitoria, por alcance o compartida a nivel de aplicación. Esto ofrece los beneficios de una instancia compartida sin el acoplamiento oculto de un Singleton programático.

Refactorizar Singletons en código legacy

Trabaja de forma incremental: identifica llamadas a MySingleton.getInstance(), define una interfaz y refactoriza consumidores uno por uno para aceptar la interfaz por constructor. Mantén la instancia concreta en la raíz de composición hasta que completes la migración.

Pasos recomendados

1. Detecta y aísla las dependencias del Singleton.
2. Define una interfaz con los métodos públicos necesarios.
3. Refactoriza consumidores para aceptar la interfaz por constructor.
4. Proporciona la instancia concreta desde la raíz de la aplicación o mediante un contenedor DI.

Esto reduce el acoplamiento oculto sin interrumpir el funcionamiento de la aplicación.

Preguntas y respuestas rápidas

¿Cuándo usar un Singleton?

Usa un Singleton con moderación: cuando el recurso debe ser verdaderamente único y sin estado crítico, como un logger central o un adaptador de hardware. Prefiere DI para mejorar testabilidad.

¿Cómo afectan los Singletons a las pruebas unitarias?

Introducen estado global que puede filtrarse entre pruebas y dificultar el mocking. La solución habitual es extraer una interfaz y permitir la inyección de dobles en los tests.

¿Cuál es la forma más segura de eliminar Singletons de una app legacy?

Mapea usos, crea una interfaz, refactoriza consumidores para aceptar la interfaz y pasa la instancia desde la raíz o mediante un contenedor DI.

Preguntas frecuentes (Q&A)

¿El Singleton mejora el rendimiento? A veces, porque evita crear recursos costosos varias veces; sin embargo, el coste de una mala arquitectura puede superar la ganancia. Revisa el caso de uso antes de decidir.

¿Puede un Singleton implementarse de forma segura en entornos concurrentes? Sí, pero hay que evitar estado mutable compartido o aplicar sincronización. En JavaScript/Node la concurrencia es cooperativa, pero en entornos multihilo o con workers conviene delegar estado a componentes thread-safe.

¿Qué ventajas ofrece un contenedor DI frente a un Singleton clásico? Un contenedor DI hace explícito el ciclo de vida de las dependencias (transitorio, por alcance, singleton a nivel de contenedor), mejora la testabilidad y reduce el acoplamiento oculto.