Vad är Singleton-mönstret?

Question

Accepted Answer

**Singleton**-mönstret säkerställer att en klass har bara **en instans** och tillhandahåller en global åtkomstpunkt till den. Det används när exakt ett objekt ska koordinera något (en konfiguration, en anslutningspool, en logger), även om det också är något kontroversiellt.

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

## Exempel

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

## Vanliga användningsfall och 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
```

## Varför det är viktigt

Att förstå Singleton-mönstret är värdefullt eftersom det är ett av de **mest välkända designmönstren** (ofta förekommande och diskuterat), och att förstå det — inklusive dess kontroverser — återspeglar god designbedömning.

Singleton säkerställer att en klass har bara en instans med global åtkomst, används när det verkligen bör finnas bara en av något (konfiguration, logger, anslutningspool, cache) som nås från många ställen.

Att förstå vad det gör (en klass kontrollerar sin egen instansiering för att returnera samma instans varje gång) är grundkunskapen.

Men att förstå **kontroversen** är lika viktig och återspeglar mogad bedömning: Singletons kritiseras brett eftersom de i huvudsak är **global state i förklädnad**, skapar **dolda beroenden** (kod som använder en Singleton har ett odeklarerat beroende), gör kod **svår att testa** (du kan inte enkelt mocka eller ersätta den enda instansen), orsakar tätt koppling och utgör samtidighetsproblem.

Att förstå att **dependency injection ofta är ett bättre alternativ** (att skicka in den enda instansen, ge samma "en instans"-fördelar men på ett testbart, explicit sätt) återspeglar designbedömningen att föredra DI framför Singletons i många fall.

Denna balanserad förståelse — att känna till mönstret men också dess problem och bättre alternativ — är vad som skiljer genomtänkt användning från cargo-culting.

Eftersom Singleton är ett av de mest välkända och ofta diskuterade mönstren, och eftersom att förstå det tillsammans med dess betydande kontroverser (global state, testbarheproblem) och dependency-injection-alternativet återspeglar god designbedömning, är förståelse för Singleton-mönstret värdefullt, allmänt relevant kunskap — ett berömt mönster värt att förstå, där att uppskatta dess brister (global state, svårt att testa) och föredra dependency injection i många fall återspeglar den mogna designbedömningen som särskiljer genomtänkta utvecklare, och ett ofta förekommande och diskuterat ämne inom mjukvarudesign.