Présentation

Le modèle Singleton est depuis des décennies la pierre angulaire des discussions sur l'ingénierie logicielle. Sa promesse, unique et accessible à l'échelle mondiale, est simple. Pourtant, au fil des ans, les développeurs l'ont célébré et critiqué. Lorsqu'ils sont utilisés correctement, Singletons gère avec élégance les ressources partagées comme les gestionnaires de configuration, les services de l'exploitation forestière ou les piscines de connexion. Lorsqu'ils sont mal appliqués, ils introduisent des couplages serrés, des dépendances cachées et des maux de tête sévères.

Quel est le modèle Singleton?

Le modèle Singleton appartient à la famille des modèles de création. Son contrat de base contient trois garanties:

  1. Une classe peut n'avoir qu'une seule instance pendant toute la durée de vie de la demande et de la demande.
  2. Cette instance doit être accessible à l'échelle mondiale de toute partie de la base de codes.
  3. La classe elle-même doit contrôler son invocation, empêchant ainsi le code externe de créer des copies supplémentaires.

Ces objectifs sont atteints en rendant le constructeur privé et en fournissant une méthode statique (souvent nommée ) qui renvoie la seule instance. Le premier appel à cette méthode crée l'objet; chaque appel ultérieur renvoie la référence mise en cache. Ce mécanisme de base a été implémenté dans d'innombrables langues, de Java et C++ à Python et JavaScript.

Pourquoi les développeurs ont-ils des points de repère pour les Singletons

Singletons résout un problème récurrent : s'assurer qu'une ressource qui devrait être singulière reste en fait singulière.

  • Connexions à la base de données: Un pool de connexion unique évite d'épuiser des ressources limitées de base de données.
  • Les fichiers de configuration:[ Chargement des paramètres une fois et leur partage empêche les E/S coûteux et l'incohérence.
  • Services d'enregistrement:[ Un enregistreur centralisé assure l'ordre déterministe et aucun conflit de fichiers.
  • Drivers de logiciels d'arrêt: Des interfaces de bas niveau comme un spooler d'imprimante ou un pilote GPU ne peuvent tolérer des instances dupliquées.

Une brève histoire du modèle Singleton

Le modèle Singleton a été officiellement documenté par le Gang of Four (GoF) dans leur livre de 1994 Design Patterns: Elements of Reusable Object-Oriented Software. Cependant, l'idée sous-jacente prédate cette publication de nombreuses années— les programmeurs avaient mis en œuvre “ un-of-a-kind” objets depuis les premiers jours de programmation orientée objet. Le GoF l'a codifié, lui a donné un nom, et a fourni des lignes directrices de mise en œuvre qui ont influencé une génération de développeurs.

À la fin des années 1990 et au début des années 2000, Singletons est devenu presque un modèle par défaut pour la gestion de l'état global. Des cadres comme Java’s Spring ont plus tard contesté cette approche en favorisant l'injection de dépendance et l'inversion du contrôle comme des alternatives plus flexibles.

Variations de la mise en œuvre de Singleton

Aucune implémentation ne fonctionne pour toutes les langues et modèles de concordance. Ci-dessous sont les variations les plus courantes, chacune avec ses propres compromis.

Initialisation de la faim

L'instance est créée lorsque la classe est chargée, avant que n'importe quel code n'appelle . C'est simple et intrinsèquement sûr des threads dans de nombreuses langues (par exemple, les initialisateurs statiques en Java sont garantis pour fonctionner une fois).

public class Singleton {
 private static final Singleton INSTANCE = new Singleton();
 private Singleton() {}
 public static Singleton getInstance() {
 return INSTANCE;
 }
}

Initialisation paresseuse (Sécurité des fils avec verrouillage double-vérifié)

Pour éviter de créer l'instance jusqu'à ce qu'elle soit réellement nécessaire, l'initialisation paresseuse reporte la construction. Dans les environnements multifilés, le motif de verrouillage double-coché classique empêche les conditions de course tout en minimisant la synchronisation des frais généraux:

public class Singleton {
 private static volatile Singleton instance;
 private Singleton() {}
 public static Singleton getInstance() {
 if (instance == null) {
 synchronized (Singleton.class) {
 if (instance == null) {
 instance = new Singleton();
 }
 }
 }
 return instance;
 }
}

Le mot-clé (en Java) empêche le ré-ordre des instructions qui pourrait faire retourner un objet partiellement construit. Ce modèle est sûr mais verbeux – des alternatives modernes existent souvent.

Bill Pugh Singleton (Idiome de l'initiateur sur demande)

Cette approche spécifique Java permet de garantir qu'une classe intérieure statique n'est pas chargée jusqu'à ce qu'elle soit référencée. Elle combine initialisation paresseuse et sécurité du thread sans synchronisation explicite:

public class Singleton {
 private Singleton() {}
 private static class Holder {
 private static final Singleton INSTANCE = new Singleton();
 }
 public static Singleton getInstance() {
 return Holder.INSTANCE;
 }
}

Enum Singleton

Le développeur Java Joshua Bloch a popularisé l'utilisation d'un pour mettre en œuvre Singletons. Cette approche offre une protection contre les attaques de réflexion et de sérialisation hors de la boîte:

public enum Singleton {
 INSTANCE;
 // add methods here
}

Les enums sont sérialisables par défaut, et le JVM assure une seule instance par constante d'enum. Pour de nombreux cas d'utilisation Java, c'est l'approche la plus sûre et la plus simple.

Singleton en Python

Python’s module system involually implementes the Singleton pattern: a module is imported only once, de sorte que les objets de niveau module se comportent comme des singletons. Pour les classes, une approche commune est de passer outre :

class Singleton:
 _instance = None
 def __new__(cls, *args, **kwargs):
 if cls._instance is None:
 cls._instance = super().__new__(cls)
 return cls._instance

Singleton en JavaScript (ES6)

Dans JavaScript moderne, les modules et les fermetures offrent des implémentations simples et propres:

const Singleton = (function() {
 let instance;
 function createInstance() {
 return { id: Math.random() };
 }
 return {
 getInstance: function() {
 if (!instance) {
 instance = createInstance();
 }
 return instance;
 }
 };
})();

Meilleures pratiques pour la mise en œuvre des monotones

Appliquer efficacement Singletons nécessite plus que de coller un extrait de code. Les lignes directrices suivantes vous aident à créer des Singletons robustes et durables.

1. Considérez toujours la sécurité des fils

Même si votre application est actuellement à un seul fil, les garanties sur l'avenir sont coûteuses à faire plus tard. Utilisez des modèles d'initialisation sans fil dès le début. L'idiome Bill Pugh (Java) ou l'initialisation avide (où la ressource est bon marché) sont des choix solides.

2. Protéger contre la réflexion et la sérialisation

Les implémentations standard de singleton peuvent être cassées via la réflexion Java (appelant le constructeur privé) ou par la désérialisation (qui crée une nouvelle instance).

  • Reflexion:[ Lancez une exception dans le constructeur si l'instance existe déjà.
  • Sérialisation: Mettre en œuvre la méthode pour renvoyer l'instance de singleton. Mieux encore, utiliser un enum singleton, qui empêche intrinsèquement les deux attaques.

3. Gardez l'Apatride Singleton chaque fois que possible

Si l'état est essentiel, testez que les transitions d'état sont sans fil. Si possible, préférez les singletons immuables : elles sont intrinsèquement sûres et plus faciles à raisonner.

4. Fournir une interface propre et intentionnelle

Exposer le singleton à travers une méthode statique clairement nommée. Évitez d'exposer la référence d'instance directement comme un champ statique public; l'utilisation d'un getter vous donne la flexibilité de changer la logique d'instantiation plus tard sans briser les clients.

5. Ne pas surestimer le modèle

Les singletons ne sont appropriés que lorsque vous avez vraiment besoin d'une seule instance et cette instance est une préoccupation transversale. Pour les méthodes d'utilité ou les fonctions pures, les méthodes statiques sont plus simples.

Pièges courants et comment les éviter

Même les développeurs expérimentés tombent dans ces pièges. Reconnaissez-les tôt pour sauver des heures de débogage.

Piège 1: Briser le Singleton avec réflexion

Comme mentionné, la réflexion peut invoquer un constructeur privé. En Java, vous pouvez ajouter un garde:

private Singleton() {
 if (INSTANCE != null) {
 throw new RuntimeException("Use getInstance() to obtain the singleton.");
 }
}

Mieux encore, utilisez un enum singleton – le JVM bloque la réflexion sur les enums.

Piège 2 : La sérialisation crée plusieurs instances

Lorsqu'un singleton implémente , la désérialisation construit un nouvel objet, contournant le constructeur privé. La correction consiste à ajouter la méthode :

protected Object readResolve() {
 return getInstance();
}

Piège 3 : Questions relatives aux chargeurs de classe

Dans des environnements comme les serveurs d'applications Java EE, plusieurs chargeurs de classes peuvent charger chaque classe de monoton, ce qui entraîne une instance par chargeur de classe.

  • Utiliser un registre statique ou une propriété système pour faire appliquer un chargeur de classe unique.
  • S'assurer que la classe singleton est chargée par un chargeur de classe partagé (parent).

Piège 4: Couvercle serré et code difficile à tester

Le code qui appelle directement est étroitement couplé à cette classe de béton. Le remplacement du singleton par une maquette ou une tige pour les essais unitaires devient presque impossible. Solution: Programmer une interface et injecter le singleton à travers un cadre ou une usine. Ou utiliser un conteneur d'injection de dépendance pour gérer la portée du singleton.

Piège 5 : État mondial et dépendances cachées

Les Singletons se comportent comme des variables globales. Au fil du temps, toute méthode de n'importe quelle classe peut appeler , créant une toile d'araignée de dépendances cachées. Cela rend le code plus difficile à comprendre, à déboguer et à maintenir. Éviter en limitant le nombre de Singletons dans votre système et en les rendant plus injectés par dépendance que accessibles au niveau mondial.

Piège 6 : Initialisation paresseuse

L'initialisation paresseuse incorrecte sans synchronisation peut faire en sorte que deux threads créent deux instances différentes, violant le modèle. Le modèle de verrouillage double-coché montré plus tôt n'est sûr que lorsqu'il est correctement mis en œuvre (volatile, ordre correct).

Essais de monotones

Le code de test qui utilise des singlets est notoirement difficile. L'approche classique est de refactorer le singlet pour utiliser une interface et une usine, puis injecter une instance de simulation pendant les tests. Par exemple, au lieu d'appeler , vous injectez une interface . Le code de production passe l'implémentation de singlets; teste passe une simulation.

Si vous devez garder le singleton, une autre technique consiste à effacer l'instance entre les tests en utilisant une méthode de réinitialisation paquet-privée (seulement pour les tests).Certains cadres, comme PowerMock en Java, permettent de moquer des méthodes statiques, mais ils viennent avec des frais généraux et devraient être un dernier recours.

La réponse la plus nette est : éviter de concevoir un code qui dépend des singlets de béton[.

Alternatives au modèle Singleton

Avant de s'engager sur un simpleton, envisagez ces alternatives qui donnent souvent une meilleure conception.

Injection de la dépendance (DI) et portée de Singleton

Les conteneurs DI (Spring, Guice, Dagger) peuvent gérer un monoton scope pour un objet particulier. Le service est inactualisé une fois par le conteneur et injecté dans tous les clients. Les clients n'appellent jamais ; ils déclarent simplement une dépendance. Cela découple le client de la classe béton et rend les tests triviaux – vous remplacez le haricot par une maquette via la configuration.

Modèle mono-étatique

Le modèle monoétate fait en sorte que état partagé plutôt qu'une seule instance. Plusieurs instances de la classe existent, mais elles partagent toutes les mêmes champs statiques. Bien que cela évite le “global singleton” stigmate, il introduit toujours l'état global et peut être confus parce que ressemble à un objet normal mais se comporte différemment.

Classe ou module statique

Si le “singleton” est simplement une collection de méthodes d'utilité apatrides, une classe statique (Java) ou un module (Python, JavaScript) est plus simple et plus explicite. Aucune gestion d'instance n'est nécessaire.

Modèle d'usine

Lorsque vous devez contrôler le nombre d'instances mais que vous voulez aussi rester flexible (p. ex., mise en commun), une usine qui retourne la même instance est une meilleure abstraction qu'une classe de monotones béton.

Modèle Singleton dans les cadres modernes

De nombreux cadres modernes découragent les implémentations explicites de Singleton.

  • Cadre de printemps:[ Les haricots sont des monotones par défaut. Vous définissez simplement un haricot une fois, et le conteneur assure une seule instance. Les développeurs écrivent rarement leur propre classe de monotones.
  • Android: Les singletons sont utilisés pour certains services système, mais le SDK Android fournit contexte comme un modèle de singleton sûr. Néanmoins, l'utilisation excessive peut causer des fuites de mémoire parce que le singleton peut contenir une référence à une Activité.
  • Node.js: Les modules du système cachent, de sorte que tout objet à l'échelle du module est effectivement un simpleton. Ceci est idiomatique et fonctionne bien pour les objets de configuration, les connexions de base de données et les instances de logger.

Cas d'utilisations mondiales réelles où Singletons Excel

Malgré les critiques, les singlets sont le bon choix dans certains scénarios :

  • Services d'enregistrement[ – Un enregistreur, un fichier, un flux de sortie.
  • Configuration de l'application – Une seule source de vérité pour les paramètres.
  • Pools de connexion – Gestion centralisée de ressources limitées.
  • Interfaces de logiciels fixes – Une seule poignée pour un appareil physique.
  • Cache managers – Un seul cache en mémoire pour éviter la duplication.

Dans chaque cas, le singleton n'est pas un crime de conception mais une décision architecturale délibérée. La clé est d'isoler le singleton derrière une interface afin que les clients ne soient pas liés à la mise en œuvre concrète.

Conclusion

Le modèle Singleton demeure un outil précieux dans la boîte à outils de l'ingénieur logiciel, mais il doit être manié avec prudence. Sa force consiste à garantir une instance et à fournir un point d'accès global – deux propriétés qui, lorsqu'elles sont combinées, peuvent facilement introduire un état global, un couplage serré et des obstacles de test. En comprenant les différentes options de mise en œuvre, en respectant les meilleures pratiques (sécurité des fils, sécurité de sérialisation, accès par interface) et en reconnaissant les pièges communs (réflexion, problèmes de charge de classe, dépendances cachées), vous pouvez prendre des décisions éclairées sur le moment et la façon d'utiliser Singletons. Dans de nombreuses bases de code modernes, les injections de dépendance et les champs gérés par cadre offrent une alternative plus durable.

Pour plus de détails, voir le classique Wikipedia article sur le modèle Singleton[, la discussion approfondie à Refactoring Guru[, et Martin Fowler’ analyse perspicace sur Patterns of Enterprise Application Architecture[.