Qu'est-ce que le pattern Singleton ?

Question

Accepted Answer

Le pattern **Singleton** garantit qu'une classe n'a qu'**une seule instance** et fournit un point d'accès global à celle-ci. Il est utilisé quand exactement un objet doit coordonner quelque chose (une configuration, un pool de connexions, un logger), bien qu'il soit aussi quelque peu controversé.

## Ce que fait 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
```

## Exemple

```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
```

## Usages courants et la controverse

```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
```

## Pourquoi c'est important

Comprendre le pattern Singleton est précieux car c'est l'un des **patterns de conception les plus connus** (fréquemment rencontré et discuté), et le comprendre — y compris ses controverses — reflète un bon jugement en matière de conception.

Singleton garantit qu'une classe n'a qu'une seule instance avec un accès global, utilisé quand il devrait véritablement n'y avoir qu'une seule instance de quelque chose (configuration, logger, pool de connexions, cache) accédée de nombreux endroits.

Comprendre ce qu'il fait (une classe contrôlant sa propre instanciation pour retourner la même instance à chaque fois) est la connaissance de base.

Cependant, comprendre la **controverse** est tout aussi important et reflète un jugement mature : les Singletons sont largement critiqués car ils sont essentiellement de l'**état global déguisé**, créant des **dépendances cachées** (le code utilisant un Singleton a une dépendance non déclarée), rendant le code **difficile à tester** (vous ne pouvez pas facilement mocker ou remplacer l'instance unique), causant un couplage serré et posant des problèmes de concurrence.

Comprendre que l'**injection de dépendances est souvent une meilleure alternative** (passer l'instance unique, fournissant le même avantage d'« une seule instance » mais de façon testable et explicite) reflète le jugement de conception de préférer l'injection de dépendances aux Singletons dans de nombreux cas.

Cette compréhension équilibrée — connaître le pattern mais aussi ses problèmes et meilleures alternatives — est ce qui distingue l'utilisation réfléchie du cargo-culting.

Puisque Singleton est l'un des patterns les plus connus et fréquemment discutés, et puisque le comprendre avec ses controverses significatives (état global, problèmes de testabilité) et l'alternative de l'injection de dépendances reflète un bon jugement de conception, comprendre le pattern Singleton est une connaissance précieuse et couramment pertinente — un pattern célèbre qui vaut la peine d'être compris, où apprécier ses inconvénients (état global, difficile à tester) et la préférence pour l'injection de dépendances dans de nombreux cas reflète le jugement de conception mature qui distingue les développeurs réfléchis, et un sujet fréquemment rencontré et discuté en conception logicielle.