Appuyez sur Entrée pour voir vos résultats ou Echap pour annuler.

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:

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:

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:

  1. La stratégie
  2. La fabrique
  3. Le décorateur

Suivez-nous par courriel!

Saisissez votre adresse courriel pour vous abonner au blog d'Ezo et recevoir une notification de chaque nouvel article par email.

Rejoignez 12 autres abonnés