Singleton

En une phrase

Le Singleton est un design pattern qui garantit qu’une classe n’a qu’une seule instance dans l’application, et que tout le code réutilise cette même instance au lieu d’en créer une nouvelle.

Une image pour comprendre

Dans ton bureau, il y a une machine à café par étage. Personne n’en achète une pour sa propre tasse : tout le monde se sert de la même. C’est ça, un Singleton. Un seul objet, et tout le monde passe par lui.

Pourquoi ça compte

En programmation objet, créer un objet a un coût. Une connexion à la base de données, un client HTTP, un service qui charge sa configuration : si chaque morceau de code refait le sien, tu gaspilles de la mémoire et du temps. Autant en créer un seul et le partager.

Tu l’utilises sans le savoir si tu fais du Spring Boot. Quand tu poses une annotation comme @Service ou @Component sur une classe, Spring en fabrique une seule instance, et la donne à tous ceux qui en ont besoin. C’est ce qu’on appelle l’injection de dépendances : tu n’écris plus new, tu demandes l’objet et Spring te le fournit.

Exemple concret

Tu as un PaiementService utilisé par dix classes différentes. Avec Spring, la documentation précise que le singleton est le mode par défaut : les dix classes reçoivent la même instance. Par défaut aussi, Spring la crée au démarrage de l’application, pas à la première utilisation, ce qui permet de découvrir tout de suite une erreur de configuration.

Attention

Un seul objet partagé par tout le monde, ça pose trois problèmes.

• L’état partagé. Si ton objet garde des données qui changent (un compteur, l’utilisateur courant), tous les threads les modifient en même temps. Les résultats deviennent imprévisibles. La documentation Spring conseille le singleton pour les objets sans état, et un objet par utilisation pour ceux qui en ont un.
• Le goulot d’étranglement. Si tu protèges cet état avec un verrou, tout le monde fait la queue devant la même machine à café. Les performances peuvent baisser.
• Les tests. Refactoring Guru relève que le Singleton classique est difficile à tester et peut cacher une mauvaise conception, parce que n’importe quelle partie du code peut s’y accrocher.

Dernier piège : le Singleton de Spring et celui du livre de référence (Gang of Four) ne marchent pas pareil. Dans le livre, la classe elle-même interdit d’en créer une deuxième. Dans Spring, c’est le conteneur qui en garde une seule, par conteneur et par bean. Si tu en déclares deux, tu en as deux.

Pour aller plus loin

• Singleton · Refactoring Guru, le pattern expliqué avec ses critiques
• Bean Scopes · la doc Spring, singleton, prototype et la différence avec le pattern du livre