Le Singleton est un patron de conception qui garantit qu’une classe n’a qu’une seule instance durant l’exécution d’un programme, tout en fournissant un point d’accès global à cette instance.
À utiliser avec précaution
Bien qu’utile pour des ressources partagées (connexion BDD, logger, cache), le Singleton introduit un état global, ce qui peut nuire à la testabilité, à la modularité et à la clarté du code.
Dans les architectures modernes (ex. : applications avec injection de dépendances), il est souvent préférable de gérer l’unicité au niveau du conteneur, pas dans la classe elle-même.
Alternative moderne (recommandée)
Dans une application utilisant un conteneur d’injection de dépendances (ex. : Symfony, Laravel, ou un PSR-11 simple), on préfère souvent :
// Dans le conteneur
$container->set(ConfigManager::class, fn () => new ConfigManager());
// Dans le code
$config = $container->get(ConfigManager::class);Un conteneur (ou container) est un outil qui dit :
« Quand on me demande tel type d’objet, je le crée une seule fois, puis je le réutilise. »
Étape 1 : Enregistrement
$container->set(ConfigManager::class, fn () => new ConfigManager());Cela veut dire :
« Chaque fois qu’on te demandera un ConfigManager, crée-le une seule fois, puis garde-le en mémoire. »
Étape 2 : Utilisation
// Dans le code
$config = $container->get(ConfigManager::class);Cela veut dire :
« Donne-moi l’instance de ConfigManager (déjà créée ou créée à la première demande). »
Singleton vs Conteneur : la différence clé
| Singleton | Conteneur | |
|---|---|---|
| Accès | ConfigManager::getInstance() → global, fixe | $container->get(...) → injecté, flexible |
| Testabilité | Très difficile (on ne peut pas facilement « simuler » la config) | Facile (on injecte un faux ConfigManager en test) |
| Couplage | Le code dépend directement de la classe ConfigManager | Le code dépend d’une interface ou d’un contrat (meilleure séparation) |
| Philosophie | « Je vais chercher moi-même mon outil » | « On me donne l’outil dont j’ai besoin » |
Analogie simple
- Singleton = aller chercher la seule cafetière de l’entreprise directement dans la cuisine.
Tout le monde sait qu’elle existe, mais si elle tombe en panne, tout le monde est bloqué.
→ Et en test ? Vous ne pouvez pas la remplacer par une tasse d’eau chaude ! - Conteneur = votre manager vous apporte une tasse de café quand vous en avez besoin.
→ Vous ne savez pas d’où il vient (machine A, B, ou thé ?).
→ En réunion importante ? Il vous apporte du déca.
→ En test ? Il vous donne de l’eau chaude → vous testez sans caféine !
Beaucoup de petits projets utilisent des Singletons ou des new directs.
Mais dès que le projet grandit, ou qu’on veut tester sérieusement, la séparation devient indispensable.