Perché tutti odiano il Singleton
Nessun design pattern ha una reputazione peggiore del Singleton. "Stato globale mascherato", "impossibile da testare", "accoppiamento nascosto" — le critiche sono note e spesso legittime. Un Singleton usato male e una variabile globale con un cappello elegante: nasconde le dipendenze, rende il codice imprevedibile e trasforma i test in un incubo di stato condiviso. In molti codebase PHP, il Singleton e il primo pattern che i developer imparano — e il primo che usano in modo sbagliato.
Eppure il Singleton esiste per un motivo. Ci sono risorse che per loro natura devono essere uniche: una connessione al database, una chiave di crittografia in memoria, la configurazione dell'applicazione. Avere due istanze di Database che aprono due connessioni diverse e un bug, non una feature. Il Singleton non e il problema — il problema e usarlo dove non serve, come scorciatoia per evitare il dependency injection.
Cos'e il Singleton Pattern: definizione e meccanica
Il Gang of Four descrive il Singleton come un pattern che "assicura che una classe abbia una sola istanza e fornisce un punto di accesso globale ad essa". L'implementazione classica prevede tre elementi: un costruttore privato (impedisce l'istanziazione diretta), una proprieta statica (conserva l'unica istanza), e un metodo statico (restituisce l'istanza, creandola al primo accesso).
