dans Programmation 101
Patron de conception : Le multiton
Présentation
Quel est le premier patron de conception qui vous vient en tête en entrevue? Le Singleton! Tellement, qu’avec le temps, je demandais au candidat de me nommer et décrire un patron de conception à part le singleton. Par contre, peut-être connaissez-vous moins son proche cousin, le Multiton?
Patron de conception : Le multiton (Multiton Pattern)
Le problème
Un singleton est une composante qui permet d’éviter d’avoir à créer des instances d’une classe et ainsi s’assurer qu’il n’y ait qu’une seule instance chargée en mémoire. Prennons par exemple, une classe de service dans une architecture orientée service (AOS). Ces classes ne possédant aucun état garantissent une fiabilité et une stabilité dans un contexte d’accès concurrentiel. Ces classes peuvent donc être des Singletons.
Par contre, nous pourrions vouloir isoler une instance afin de lui donner un état en plus d’un comportement afin de gérer l’accès concurentiel. Dans un contexte d’application mono-page bâtie sur des services REST sans état, il peut être utile de stoker des données sur le destinateur d’une requête, par exemple, pour éviter une attaque par le rejeu.
La solution
Grâce au multiton, il est possible de gérer les instances d’une classe, c’est-à-dire offrir un point d’entrée principal pour la création d’instances comme le Singleton le fait, mais aussi d’autoriser la création de plus d’une instance. De sorte, nous créons une instance qui est associée à une clé.
Rafraichissons-nous la mémoire concernant le Singleton:
|
1 2 3 4 5 6 7 8 9 10 11 |
class Singleton { private static Singleton instance; private Singleton() { // No "new Singleton()" } public static Singleton getInstance() { return Singleton.instance == null ? Singleton.instance = new Singleton() : Singleton.instance; } } |
La règle est simple: Un constructeur privé bloquant la création d’instance à l’aide de new, un attribut de classe contenant la seule instance autorisée de la classe, un accesseur pour l’instance qui la crée au besoin et la retourne. On peut appeler ce Singleton comme étant Singleton paresseux (lazy)… Paresseux ou lazy ici signifie que l’instance est créée au besoin.
Vous l’aurez donc deviné, il est possible d’autoriser plusieurs instances, mais une seule pour une clé, grâce à un dictionnaire ou une Map. Pour garder le côté lazy, on pourrait donc obtenir une classe qui ressemble à ceci:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
public class Multiton { private static Map<String, Multiton> instances = new HashMap<>(); private Multiton() { System.out.println("Multiton instance created..."); } public static Multiton getInstance(String param) { Multiton returnedInstance = Multiton.instances.get(param); if (returnedInstance == null) { returnedInstance = new Multiton(); Multiton.instances.put(param, returnedInstance); } else { System.out.println("Instance found for " + param + " = " + returnedInstance.toString()); } return returnedInstance; } } |
Ainsi, en gardant en mémoire ces instances, nous nous assurons que, pour une clé quelconque, il n’y aura qu’une seule instance.
Conclusion
Voilà qui conclut cette mini série d’articles sur les patrons de conception que je qualifierais de primordiaux pour tous les développeurs. Rappelez-vous: un patron de conception répond à des problèmes courants. La solution existe et elle est simple.
Je vous invite à utiliser la section des commentaires ci-dessous pour me suggérer un patron de conception que j’aurais pû oublier et que vous jugez important à connaître. Il en existe plusieurs, soyez créatifs!
Je vous invite aussi à lire ou relire les articles passés de la série:
Commentaires
Laisser un commentaire