Cet article explique comment le modèle Singleton n'applique qu'une seule instance d'une classe pour être produite et exister pendant toute la durée de vie d'une application.

Qu'est-ce que c'est?

Un singleton est un modèle de conception utilisé pour créer la seule instance de classe. Le modèle singleton est généralement utilisé lorsqu'il existe plusieurs exemples dans lesquels une seule instance d'une classe doit exister et la contrainte doit être appliquée. Par exemple, les caches, les pools de threads et les registres ne doivent avoir qu'une seule instance.

Rendez le constructeur privé pour vous assurer qu'un seul objet de classe est créé. De cette façon, seuls les membres de la classe peuvent accéder au constructeur privé et personne d'autre.

Dans le monde réel, le modèle Singleton garantit qu'une seule instance de classe existe et offre un point d'accès global à celle-ci.

Diagramme de classe

Le diagramme de classes contient une seule entité.

Singleton

Exemple

Disons que nous voulons modéliser l'avion officiel du président américain appelé Airforce One dans notre logiciel. La classe Singleton est la représentation la mieux adaptée pour une entité avec une seule instance.

Voici le code de notre classe singleton :

Multithreading et Singleton

Ce code fonctionne tant que l'application est monothread. Cependant, si plusieurs threads accèdent à cette classe, il est possible que divers objets soient créés.

Par exemple:

• Le thread A appelle la méthode getInstanceet trouve que la onlyInstancevaleur est nulle ; cependant, avant de pouvoir créer une instance, le contexte est désactivé.
• Maintenant, le thread B arrive et appelle getInstance, qui renvoie l' AirforceOneobjet.
• Si le thread A est programmé à nouveau, le méfait commence. Le thread a déjà dépassé la vérification de la condition if-null et procédera à la création d'un nouvel AirforceOneobjet et l'affectera à onlyInstance. Maintenant, il y a deux AirforceOneobjets différents dans la nature, l'un avec le fil A et l'autre avec le fil B.

• En ajoutant synchronizedà la getInstance()méthode, vous pouvez obtenir la sécurité des threads.

• Une autre option consiste à initialiser l'instance de manière statique, en garantissant qu'elle est thread-safe.

Verrouillage à double contrôle

Il existe deux problèmes importants avec les approches décrites ci-dessus : la synchronisation est coûteuse et l'initialisation statique crée l'objet même s'il n'est pas utilisé dans une application particulière. Si la création d'un objet est coûteuse, l'initialisation statique peut nous coûter en performances.

La solution ci-dessus marque l'instance singleton volatile. Cependant, cette implémentation de la volatileméthodologie de la JVM ne fonctionnera pas correctement pour le verrouillage à double vérification, et vous aurez besoin d'une autre approche pour créer vos singletons.

L' idiome de verrouillage à double vérification est maintenant considéré comme un anti-modèle, et son utilité a principalement disparu à mesure que les temps de démarrage de la JVM se sont accélérés.

Autres exemples

L'API Java nous fournit les singletons suivants :

java.lang.Runtime

java.awt.Desktop

Mises en garde

Vous pouvez sous-classer une classe singleton en protégeant le constructeur au lieu de private. Cependant, il existe de meilleurs choix que cela en toutes circonstances. Dans ces situations, les développeurs peuvent créer un registre de singletons pour toutes les sous-classes. La méthode getInstance peut prendre un paramètre ou utiliser une variable d'environnement pour renvoyer l'objet singleton souhaité. Le registre maintient un mappage des noms de chaîne aux objets singleton.

Autres articles de la série Creational Pattern

• Modèle de création : constructeur
• Modèle de création : prototype
• Modèle de création : méthode d'usine
• Modèle de création : usine abstraite