¿Qué es el patrón Singleton?

Question

Accepted Answer

El patrón **Singleton** asegura que una clase tenga solo **una instancia** y proporciona un punto de acceso global a ella. Se utiliza cuando exactamente un objeto debe coordinar algo (una configuración, un pool de conexiones, un logger), aunque también es algo controvertido.

## Qué hace Singleton

```text
SINGLETON → guarantee a class has only ONE instance, with global access to it:
  → the class controls its own instantiation (private constructor)
  → returns the SAME instance every time it's requested
→ for: things there should only be ONE of, accessed from many places
```

## Ejemplo

```js
class Config {
  static #instance;
  static getInstance() {
    if (!Config.#instance) {
      Config.#instance = new Config();   // create once
    }
    return Config.#instance;             // always return the same instance
  }
}
// Config.getInstance() always returns the same object
```

## Usos comunes y la controversia

```text
USES → configuration objects, loggers, connection pools, caches (one shared instance)
⚠️ CONTROVERSIAL → Singletons are often criticized:
  → GLOBAL STATE in disguise → hidden dependencies, hard to TEST (can't easily mock/replace),
    tight coupling, issues with concurrency
  → often better: DEPENDENCY INJECTION (pass the single instance in) → same "one instance"
    benefit but testable and explicit
→ use sparingly; consider DI as an alternative; valid for genuinely-single resources
```

## Por qué es importante

Comprender el patrón Singleton es valioso porque es uno de los **patrones de diseño más conocidos** (frecuentemente encontrado y discutido), y comprenderlo — incluyendo sus controversias — refleja buen juicio de diseño.

Singleton asegura que una clase tenga solo una instancia con acceso global, utilizado cuando genuinamente debe haber solo uno de algo (configuración, logger, pool de conexiones, caché) accedido desde muchos lugares.

Comprender qué hace (una clase controlando su propia instanciación para devolver la misma instancia cada vez) es el conocimiento básico.

Sin embargo, comprender la **controversia** es igualmente importante y refleja juicio maduro: Los Singletons son ampliamente criticados porque son esencialmente **estado global disfrazado**, creando **dependencias ocultas** (el código que usa un Singleton tiene una dependencia no declarada), haciendo código **difícil de probar** (no puedes fácilmente hacer mock o reemplazar la única instancia), causando acoplamiento fuerte y planteando problemas de concurrencia.

Comprender que **la inyección de dependencias es a menudo una mejor alternativa** (pasando la única instancia, proporcionando el mismo beneficio de "una instancia" pero de manera comprobable y explícita) refleja el juicio de diseño de preferir DI sobre Singletons en muchos casos.

Esta comprensión equilibrada — conocer el patrón pero también sus problemas y mejores alternativas — es lo que distingue el uso reflexivo del cargo-culting.