Singleton Abusato - Antipattern Pattern

Il Problema

Un Singleton globale crea dipendenze nascoste, rende il testing difficile (impossibile mockare o isolare), introduce accoppiamento forte e bug difficili da tracciare quando un modulo modifica lo stato condiviso. Viola il principio di dependency injection.

La Soluzione

Passare dipendenze come parametri (Dependency Injection). Usare configurazioni immutabili. Preferire scope locale a stato globale. Singleton dovrebbe essere usato solo per risorse davvero condivise (connection pool, logger).

Struttura

Invece di Config globale singleton, passare config come parametro alle funzioni. Permette testing con diverse configurazioni e elimina stato globale mutabile.

Partecipanti:

Dependency Injection - passa config come parametro

Immutable Config - configurazioni non modificabili

Factory/Builder - crea istanze con config specifiche

Esempi di Codice

PROBLEMA: Singleton Abusato - Config globale mutabile

Config singleton crea dipendenze nascoste e rende il testing impossibile.

SOLUZIONE: Dependency Injection e config immutabile

Passare config come parametro. Testing isolato e dipendenze esplicite.

Esempi di Errori Comuni

Config globale modificabile da qualsiasi modulo

Service Locator pattern (dipendenze nascoste)

Cache singleton senza possibilità di isolamento nei test

Feature flags globali invece di parametri espliciti

Perché Evitarlo

Per config, preferenze utente, feature flags

Come Correggerlo

Usa Dependency Injection per config

Passa parametri esplicitamente

Config immutabili (Object.freeze)

Singleton OK solo per: logger, connection pool, thread pool

Pattern Correlati