Czym jest wzorzec Singleton?

Question

Accepted Answer

Wzorzec **Singleton** zapewnia, że klasa ma tylko **jedną instancję** i zapewnia globalny punkt dostępu do niej. Jest używany, gdy dokładnie jeden obiekt powinien koordynować coś (konfigurację, pulę połączeń, logger), choć wzorzec ten jest też nieco kontrowersyjny.

## Co robi 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
```

## Przykład

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

## Typowe zastosowania i kontrowersje

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

## Dlaczego to ważne

Zrozumienie wzorca Singleton jest wartościowe, ponieważ jest to jeden z **najsławniejszych wzorców projektowych** (często spotykany i omawiany), a jego zrozumienie — w tym jego kontrowersji — odzwierciedla dobre osądy dotyczące projektowania.

Singleton zapewnia, że klasa ma tylko jedną instancję z globalnym dostępem, używaną, gdy powinno naprawdę istnieć tylko jedno coś (konfiguracja, logger, pula połączeń, cache) dostępne z wielu miejsc.

Zrozumienie tego, co robi (klasa kontrolująca własną instancjację, aby zwrócić tę samą instancję za każdym razem), jest podstawową wiedzą.

Jednak równie ważne jest zrozumienie **kontrowersji**: Singletony są powszechnie krytykowane, ponieważ są zasadniczo **stanem globalnym w przebraniu**, tworzą **ukryte zależności** (kod używający Singletona ma niezadeklarowaną zależność), czynią kod **trudnym do testowania** (nie można łatwo mockować ani zastąpić pojedynczej instancji), powodują ścisłe powiązania i stwarzają problemy współbieżności.

Zrozumienie, że **wstrzykiwanie zależności jest często lepszą alternatywą** (przekazywanie pojedynczej instancji, zapewniające ten sam benefit "jednej instancji", ale w testowany, jawny sposób) odzwierciedla osąd projektowy polegający na preferowaniu DI zamiast Singletonów w wielu przypadkach.

To zrównoważone zrozumienie — znanie wzorca, ale także jego problemów i lepszych alternatyw — to to, co odróżnia przemyślane zastosowanie od cargo cultu.

Ponieważ Singleton jest jednym z najsławniejszych i najczęściej omawianych wzorców, a zrozumienie go wraz z jego istotnymi kontrowersyjami (stan globalny, problemy z testowalnością) oraz alternatywą wstrzykiwania zależności odzwierciedla dobre osądy dotyczące projektowania, wiedza na temat wzorca Singleton jest wartościowa i powszechnie istotna — sławny wzorzec godny zrozumienia, gdzie docenianie jego wad (stan globalny, trudno testować) i preferencja dla wstrzykiwania zależności w wielu przypadkach odzwierciedla dojrzały osąd projektowy, który odróżnia przemyślanych deweloperów, oraz temat często spotykany i omawiany w projektowaniu oprogramowania.