Hvad er Singleton-mønstret?

Question

Accepted Answer

Mønstret **Singleton** sikrer, at en klasse har kun **én instans** og giver et globalt adgangspunkt til den. Det bruges, når præcis ét objekt skal koordinere noget (en konfiguration, en forbindelsespulje, en logger), selvom det også er noget kontroversielt.

## Hvad Singleton gør

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

## Eksempel

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

## Almindelig brug og kontroversen

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

## Hvorfor det betyder noget

At forstå Singleton-mønstret er værdifuldt, fordi det er et af de **mest velkendte designmønstre** (hyppigt mødt og diskuteret), og at forstå det — inklusive dets kontrovers — afspejler god designvurdering.

Singleton sikrer, at en klasse har kun én instans med globalt adgang, brugt når der virkelig kun burde være ét af noget (konfiguration, logger, forbindelsespulje, cache) adgang fra mange steder.

At forstå hvad det gør (en klasse kontrollerer sin egen instantiering for at returnere den samme instans hver gang) er grundlæggende viden.

Men at forstå **kontroversen** er lige så vigtig og afspejler modent skøn: Singleton bliver bredt kritiseret, fordi det i det væsentlige er **global tilstand i forklædning**, der skaber **skjulte afhængigheder** (kode, der bruger en Singleton, har en udeklareret afhængighed), hvilket gør koden **svær at teste** (du kan ikke nemt mocke eller erstatte den enkelte instans), forårsager tæt kobling og skaber samtidigheds problemer.

At forstå, at **afhængighedsinjektion ofte er et bedre alternativ** (videregive den enkelte instans, hvilket giver den samme "en instans"-fordel men på en testbar, eksplicit måde) afspejler designvurderingen at foretrække DI frem for Singletons i mange tilfælde.

Denne balancerede forståelse — at kende mønstret men også dets problemer og bedre alternativer — er hvad der adskiller tankefuls brug fra cargo-culting.