Le patron Singleton permet de créer une classe qui n'a qu'un seul objet.
C'est en pratique utile pour une ressource centralisé qui est utilisée à de nombreux endroits d'un projet.
Exemples:
Le patron Singleton ressemble beaucoup à une variable globale à toute l'application.
Il introduit une dépendance entre la classe qui implémente ce patron et
toutes les classes qui l'utilise.
Il est en contradiction avec les principes SOLID.
Il est assez rare que ce soit la bonne réponse à votre problème.
Nous vous le présentons car ce patron est très utilisé dans les frameworks logiciels (en particulier ceux de JEE) en conjonction avec l'injection de dépendance.
L'implémentation en Java est simple et robuste (prise du cours de M. Forax).
public class DB { // champs de l'objet private DB(){ // initialisation des champs } private static final DB INSTANCE = new DB(); public static DB getInstance(){ return INSTANCE; } }
Le constructeur étant privé, il ne peut pas y avoir d'autre objet que INSTANCE.
L'implémentation vue au transparent précédent est thread-safe.
En effet, le modèle de mémoire de Java garantie que les variables statiques sont visibles (entièrement construite) dans tous les threads qui utilise la classe.
Attention si la classe est mutable, il faudra quand même faire en sorte qu'elle soit thread-safe.
On parle de création paresseuse (lazy en anglais) quand l'instance du singleton est crée à sa première utilisation et pas au démarrage du programme.
L'implémentation que nous avons vu est paresseuse car en Java, les classes ne sont chargées qu'au moment de leur première utilisation.
Attention, ce n'est pas le cas dans tous les langages objets (par exemple en C++) et il faudra donc se renseigner si l'on implémente le singleton dans un autre langage.