Singleton
Catégorie
Pattern créationnel
Problème
Assurer qu’une classe n’a qu’une seule instance dans toute l’application et fournir un point d’accès global à celle-ci. Utile pour coordonner des actions à l’échelle du système, telles que la gestion de configuration ou le pooling de connexions.
Solution
- Rendre le constructeur de la classe privé pour empêcher l’instanciation externe
- Créer une méthode statique qui retourne l’instance unique
- Initialiser paresseusement l’instance au premier accès
- Utiliser des mécanismes thread-safe (verrouillage, double-checked locking) pour l’accès concurrent
Structure
- Singleton :
- Variable d’instance statique privée
- Constructeur privé
- Méthode statique publique
getInstance() - Mécanisme d’initialisation thread-safe
Avantages clés
- Accès contrôlé — Exactement une instance, pas d’ambiguïté
- Point d’accès global — Disponible de n’importe où dans l’application
- Initialisation paresseuse — L’instance est créée uniquement quand elle est nécessaire
- Empreinte mémoire réduite — Une seule instance existe pendant toute la durée de vie de l’application
Compromis
- Viol du Single Responsibility Principle — Gère son propre cycle de vie
- Difficile à tester — L’état global rend les tests unitaires plus difficiles ; nécessite du mocking
- Complexité de thread-safety — Nécessite un traitement soigné dans les environnements concurrents
- Peut devenir une dépendance cachée — Rend difficile de voir où l’instance est utilisée
Quand l’utiliser
- Exactement une instance d’une classe est nécessaire (par exemple, pool de connexions de base de données, gestionnaire de configuration, service de journalisation)
- Une initialisation paresseuse est nécessaire pour reporter la création d’objets coûteux
- L’instance doit être accessible de n’importe où sans passer de références