Le patron Singleton promet un repère unique dans une application : une configuration partagée, un journal central ou un gestionnaire de ressources, par exemple. Mais derrière cette simplicité se cachent des choix importants, notamment en matière de tests et de sécurité des threads. Des exemples en Java, C++, PHP et Python permettent de comprendre quand cette instance unique rend réellement service — et quand une autre approche sera plus souple.
L’article en bref
Le Singleton centralise une instance, mais son accès global peut aussi rendre le code plus difficile à tester. Voici comment choisir une implémentation adaptée à votre langage et à vos contraintes.
- Principe : Une classe contrôle sa création et fournit une instance partagée.
- Usages : Configuration, journalisation et ressources communes peuvent justifier cette centralisation.
- Langages : Java, C++, PHP et Python proposent des approches différentes.
- Vigilance : Tests, état partagé et concurrence imposent de mesurer ses limites.
Le bon réflexe : vérifier d’abord si une dépendance explicite ne ferait pas mieux.
Patron Singleton : principe et fonctionnement
Le Singleton appartient aux patrons de création. Son objectif est de limiter une classe à une instance unique et de proposer un accès global à celle-ci. Plutôt que de construire librement de nouveaux objets, le code demande l’instance à un point d’entrée contrôlé.
Imaginez l’application d’un petit studio de jeux, Atelier Nébuleuse. Plusieurs modules doivent lire les mêmes paramètres de lancement : un Singleton de configuration peut éviter qu’ils travaillent chacun avec une copie différente. Le principe est simple, mais il ne garantit pas à lui seul que le choix soit pertinent.
Constructeur privé et initialisation paresseuse
Dans les langages orientés objet, une implémentation classique associe un constructeur privé à une méthode ou propriété d’accès. La classe empêche ainsi les appels directs à son constructeur et crée l’objet lorsqu’il est demandé, si aucune instance n’existe encore.
Cette création à la demande porte le nom d’initialisation paresseuse. Elle peut éviter de construire trop tôt un objet coûteux, mais elle ajoute une logique de création qu’il faut maîtriser, en particulier lorsque plusieurs threads sollicitent l’instance au même moment.
Quand utiliser le Singleton, et quand s’en méfier
Le pattern est utile lorsque le système a réellement besoin d’un service partagé et unique dans un périmètre donné : paramètres communs, registre de ressources ou accès à un service centralisé. Il peut aussi éviter des créations répétées, mais le gain de mémoire ou de vitesse dépend du cas concret et ne doit pas être présumé.
Le revers apparaît quand l’instance devient un conteneur d’état global. Un changement effectué par un module peut alors affecter un autre module sans que le lien soit visible dans ses paramètres. Les tests deviennent également plus délicats : une instance conservée entre deux scénarios peut laisser des données résiduelles.
- À envisager : une ressource réellement unique dans le périmètre de l’application.
- À éviter : transformer chaque service pratique en état global par défaut.
- À vérifier : la durée de vie, le partage entre processus et les besoins de test.
- À préférer parfois : injecter explicitement une dépendance dans les composants qui en ont besoin.
Dans Atelier Nébuleuse, un objet de configuration immuable peut être partagé sans difficulté majeure. En revanche, un Singleton qui mêle configuration, sauvegarde et statistiques risque de devenir un point de passage encombré : l’unicité ne remplace pas une conception claire.
Sécurité des threads : le piège de la création simultanée
Dans une application multithread, deux tâches peuvent constater en même temps qu’aucune instance n’existe et tenter de la construire. Une implémentation naïve peut alors créer deux objets, ce qui contredit précisément la promesse du Singleton. La sécurité des threads dépend donc de la manière dont le langage et la stratégie choisie encadrent l’initialisation.
La double vérification avec verrou, souvent appelée double-checked locking, a connu des implémentations incorrectes en Java lorsque les garanties du modèle mémoire n’étaient pas respectées. Il ne suffit pas d’ajouter un verrou à une vérification rapide : la publication de l’objet doit elle aussi être sûre. Des mécanismes intégrés au langage sont généralement préférables aux recettes recopiées sans contexte.
Exemples du patron Singleton en Java, C++, PHP et Python
Les langages ne proposent pas tous le même modèle de création. Les exemples suivants privilégient des formes concises et reconnues, plutôt qu’une unique recette transposée partout.
Java : préférer une forme sûre et lisible
En Java, une énumération à valeur unique constitue une option robuste pour représenter un Singleton : public enum Config { INSTANCE; }. L’accès se fait ensuite avec Config.INSTANCE. Cette forme bénéficie des garanties du langage concernant la création de l’énumération et résiste aussi à plusieurs problèmes liés à la sérialisation.
Pour une initialisation paresseuse, une classe imbriquée statique peut convenir : la classe porte une instance statique finale, et le chargeur de classes ne l’initialise qu’à son premier usage. Ce mécanisme évite de gérer soi-même un verrou dans la plupart des cas. Le choix dépend notamment du besoin de sérialisation, du cycle de vie et de la compatibilité recherchée.
C++ : l’objet statique local de Meyers
Depuis C++11, l’initialisation d’un objet statique local est synchronisée par le langage. Une implémentation courante prend cette forme : static Service& instance() { static Service objet; return objet; }. L’objet est créé au premier appel et réutilisé ensuite.
Pour préserver le contrôle de création, le constructeur de Service doit être rendu inaccessible au code extérieur, par exemple en le déclarant privé et en autorisant la fonction concernée à y accéder. Attention toutefois à la durée de vie à la fermeture du programme et à l’ordre de destruction entre objets globaux : le Singleton ne règle pas automatiquement ces questions.
PHP : contrôler la création et le clonage
En PHP, une classe peut conserver son instance dans une propriété statique et exposer une méthode getInstance(). Le constructeur et la méthode de clonage sont généralement privés pour empêcher la création ou la copie depuis l’extérieur. Une forme simplifiée s’écrit ainsi : private static ?Service $instance = null;, puis une méthode statique qui crée l’objet si la propriété est vide et le renvoie dans tous les cas.
Dans une application web, le Singleton concerne habituellement une instance au sein du processus ou de la requête selon le modèle d’exécution ; il ne signifie pas nécessairement qu’un seul objet existe à l’échelle de tous les serveurs. Le périmètre réel doit être vérifié avant d’y placer un état partagé.
Python : un module suffit souvent
En Python, un module importé est mis en cache dans le processus. Un module qui expose un objet configuré peut donc fournir un service partagé sans imposer une classe Singleton dédiée. Cette solution, discrète et idiomatique, est souvent plus facile à lire qu’une personnalisation de la création des objets.
Il est aussi possible de contrôler la construction avec __new__, mais il faut alors traiter avec soin les appels répétés à __init__ et les accès concurrents. Une variante appelée Borg partage l’état entre plusieurs objets au lieu de garantir leur identité : deux références peuvent désigner des instances distinctes, tout en utilisant le même dictionnaire d’état.
| Langage | Approche pratique | Point de vigilance |
|---|---|---|
| Java | Énumération à valeur unique ou classe imbriquée statique | Choisir selon sérialisation et besoin d’initialisation paresseuse |
| C++ | Objet statique local, avec les garanties de C++11 et versions suivantes | Considérer la durée de vie et l’ordre de destruction |
| PHP | Propriété statique et méthode d’accès contrôlée | Définir le périmètre de l’instance selon l’exécution |
| Python | Module partagé, souvent suffisant et plus idiomatique | Éviter une classe complexe sans besoin d’identité unique |
Le langage donne les outils, mais c’est le périmètre d’unicité qui décide si l’architecture reste saine.
Choisir une alternative au Singleton global
Un service n’a pas toujours besoin d’être accessible partout pour être partagé. La dependency injection permet de créer l’objet au niveau de l’application, puis de le transmettre explicitement aux composants concernés. Le lecteur voit alors de quoi dépend un module, et les tests peuvent lui fournir une version dédiée ou simulée.
Si le besoin porte surtout sur des valeurs communes, une configuration immuable peut suffire. Si plusieurs instances doivent partager leurs données, l’approche Borg de Python ou un composant de stockage dédié peut mieux exprimer cette intention. La question utile n’est donc pas seulement « combien d’objets ? », mais « qui contrôle l’état et pendant combien de temps ? »
Repères avant d’adopter le patron Singleton
Avant de centraliser un service, quelques vérifications évitent de transformer une commodité locale en dépendance difficile à défaire. Elles sont particulièrement utiles quand le projet grandit ou que les tests commencent à s’isoler les uns des autres.
- Définir le périmètre : l’unicité concerne-t-elle une classe, un processus, une requête ou plusieurs machines ?
- Évaluer l’état : l’objet est-il immuable, ou ses modifications auront-elles des effets indirects ?
- Choisir l’initialisation : une construction immédiate est-elle suffisante, ou la paresse apporte-t-elle un bénéfice réel ?
- Tester la concurrence : plusieurs threads ou tâches peuvent-ils demander l’objet simultanément ?
- Préserver la testabilité : peut-on remplacer facilement le service dans un scénario de test ?
Un Singleton bien choisi reste un outil ciblé, pas une règle générale de conception. Plus son rôle est étroit et explicite, plus il est simple à maintenir.
Questions fréquentes sur le design pattern Singleton
Le Singleton garantit-il une seule instance dans toute l’application ?
Pas toujours. L’unicité dépend du périmètre d’exécution : chargeur de classes en Java, processus, requête ou instance de serveur. Dans un déploiement réparti, chaque processus peut posséder son propre objet.
Le Singleton est-il forcément plus performant ?
Non. Il peut éviter certaines créations répétées, mais ajoute aussi une gestion d’accès et parfois de synchronisation. Il faut mesurer le coût réel et ne pas choisir ce patron sur une promesse générale de performance.
Quelle implémentation Java choisir ?
Une énumération à valeur unique est une option simple et robuste dans de nombreux cas. Une classe imbriquée statique convient notamment si l’initialisation doit rester paresseuse. Le contexte du projet et les besoins de sérialisation comptent dans le choix.
Le Singleton est-il adapté à Python ?
Il peut l’être, mais un module partagé répond souvent au même besoin avec moins de mécanismes. Une classe dédiée se justifie surtout lorsque l’identité unique fait réellement partie du contrat de conception.
Je suis Hugo Vasseur, rédacteur spécialisé culture pop : bande dessinée, mangas et comics, mais aussi cinéma, séries, jeux et sorties. Ancien libraire passionné devenu journaliste, j’aime expliquer par où commencer, dans quel ordre lire ou regarder, et ce qui vaut vraiment le détour. Sur Ex Libris, je partage des guides clairs et enthousiastes — sans jargon et sans spoilers gratuits.
