Che cos'è il pattern Singleton?

Question

Accepted Answer

Il pattern **Singleton** assicura che una classe abbia **una sola istanza** e fornisce un punto di accesso globale ad essa. Viene utilizzato quando esattamente un oggetto dovrebbe coordinare qualcosa (una configurazione, un pool di connessioni, un logger), anche se è anche alquanto controverso.

## Cosa fa 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
```

## Esempio

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

## Usi comuni e 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
```

## Perché è importante

Comprendere il pattern Singleton è prezioso perché è uno dei **pattern di progettazione più noti** (frequentemente incontrato e discusso), e comprenderlo — incluse le sue controversie — riflette un buon giudizio di progettazione.

Singleton assicura che una classe abbia una sola istanza con accesso globale, utilizzato quando genuinamente dovrebbe esserci solo uno di qualcosa (configurazione, logger, pool di connessioni, cache) a cui accedere da molti posti.

Comprendere cosa fa (una classe che controlla la propria istanziazione per restituire la stessa istanza ogni volta) è la conoscenza di base.

Tuttavia, comprendere la **controversia** è ugualmente importante e riflette un giudizio maturo: i Singleton sono ampiamente criticati perché sono essenzialmente **stato globale mascherato**, creando **dipendenze nascoste** (il codice che usa un Singleton ha una dipendenza non dichiarata), rendendo il codice **difficile da testare** (non puoi facilmente mockare o sostituire la singola istanza), causando accoppiamento stretto e creando problemi di concorrenza.

Comprendere che l'**iniezione delle dipendenze è spesso un'alternativa migliore** (passando l'istanza singola, fornendo lo stesso beneficio di "una sola istanza" ma in modo testabile e esplicito) riflette il giudizio di progettazione di preferire l'iniezione delle dipendenze ai Singleton in molti casi.

Questa comprensione equilibrata — conoscere il pattern ma anche i suoi problemi e alternative migliori — è ciò che distingue l'uso consapevole dal cargo-culting.

Poiché Singleton è uno dei pattern più noti e frequentemente discussi, e poiché comprenderlo insieme alle sue significative controversie (stato globale, problemi di testabilità) e l'alternativa dell'iniezione delle dipendenze riflette un buon giudizio di progettazione, comprendere il pattern Singleton è una conoscenza preziosa e comunemente rilevante — un pattern famoso che vale la pena comprendere, dove apprezzare i suoi difetti (stato globale, difficile da testare) e la preferenza per l'iniezione delle dipendenze in molti casi riflette il giudizio di progettazione maturo che distingue gli sviluppatori consapevoli, e un argomento frequentemente incontrato e discusso nella progettazione del software.