Compositions et variations de patterns

1. Introduction

Nous avons introduit dans un précédent chapitre le pattern Abstract Factory pour abstraire la création (instanciation) de produits de leurs différentes familles. Une fabrique est alors associée à chaque famille de produits. Sur le diagramme de la figure 5-1.1, deux produits sont exposés : les automobiles et les scooters, décrits chacun par une classe abstraite. Ces produits sont organisés en deux familles : traction essence et traction à l’électricité. Chacune de ces deux familles engendre une sous-classe concrète de chaque classe de produit.

Il existe donc deux fabriques pour les familles FabriqueVéhiculeEssence et FabriqueVéhiculeÉlectricité. Chaque fabrique permet de créer l’un des deux produits à l’aide des méthodes appropriées.

Ce pattern organise de façon très structurée la création d’objets. Chaque nouvelle famille de produits oblige à ajouter une nouvelle fabrique et donc une nouvelle classe.

À l’opposé, le pattern Prototype introduit dans le chapitre du même nom offre la possibilité de créer des nouveaux objets de façon très souple.

Figure 5-1.1 - Exemple d’utilisation du pattern Abstract Factory

La structure du pattern Prototype est décrite à la figure 5-1.2. Un objet initialisé afin d’être prêt à l’emploi et détenant la capacité de se dupliquer est appelé un prototype.

Le client dispose d’une liste de prototypes qu’il peut dupliquer lorsqu’il le désire. Cette liste est construite dynamiquement et peut être modifiée à tout moment lors de l’exécution. Le client peut ainsi construire de nouveaux objets sans connaître la hiérarchie des classes dont ils proviennent.

Figure 5-1.2 - Exemple d’utilisation du pattern Prototype

L’idée du pattern Pluggable Factory est de composer ces deux patterns pour conserver l’idée de création d’un produit par l’invocation d’une méthode de la fabrique et d’autre part, de pouvoir changer dynamiquement la famille à créer. Ainsi, la fabrique ne doit plus connaître...

1. Discussion

Nous avons introduit dans un chapitre précédent le pattern Visitor afin de pouvoir ajouter de nouvelles fonctionnalités à un ensemble de classes sans devoir modifier ces classes à chaque ajout. Chaque nouvelle fonctionnalité donne lieu à une classe de visiteur qui implante cette fonctionnalité en introduisant un ensemble de méthodes, une pour chaque classe. Toutes ces méthodes portent le même nom, par exemple visite et ont un seul paramètre dont le type est celui de la classe pour laquelle la fonctionnalité est implantée. 

Toutefois pour implanter le pattern Visitor, les classes devant être visitées subissent une légère modification, à savoir l’introduction d’une méthode pour accepter le visiteur, méthode dont le seul but est d’invoquer la méthode visite avec un paramètre correctement typé. Le nom de cette méthode est souvent accepte ou accepteVisiteur.

La figure 5-1.5 montre une mise en œuvre du pattern Visitor dans le but de visiter une hiérarchie d’objets décrite à l’aide du pattern Composite. Ces objets sont des sociétés dont certaines, les sociétés mères, possèdent des filiales. Les deux fonctionnalités ajoutées sont le calcul des coûts d’entretien et la possibilité d’envoi d’un mailing commercial à une société en incluant toutes ses filiales, y compris les filiales des filiales. La méthode accepteVisiteur de la classe SociétéMère inclut une boucle foreach demandant à chacune des filiales d’accepter à son tour le visiteur.

Figure 5-1.5 - Application du pattern Visitor à un ensemble de sociétés

Le pattern Reflective Visitor est une variante du pattern Visitor qui utilise la capacité de réflexion structurelle du langage de programmation afin que la mise en œuvre ne nécessite pas l’introduction de la méthode d’acceptation du visiteur dans les classes devant être visitées. La réflexion structurelle d’un langage de programmation est sa capacité à fournir un moyen d’examiner l’ensemble des classes...

1. Description et exemple

Le but du pattern Multicast est de gérer les événements produits dans un programme afin de les transmettre à un ensemble de récepteurs concernés. Le pattern est basé sur un mécanisme d’inscription des récepteurs auprès des expéditeurs. 

Nous voulons mettre en œuvre un programme d’envoi de messages entre les directions (générale, commerciale, financière, etc.) d’un concessionnaire et ses employés.

Chaque employé peut s’inscrire auprès de la direction à laquelle il appartient et recevoir ainsi tous les messages émis par cette dernière. Un employé ne peut pas s’inscrire auprès d’une direction à laquelle il n’appartient pas. Tous les employés peuvent bien sûr s’inscrire auprès de la direction générale afin d’en recevoir les messages.

La structure des messages peut varier d’une direction à l’autre : simple ligne de texte pour les messages commerciaux, liste de lignes pour les messages généraux provenant de la direction générale.

Le diagramme de classes de la figure 5-1.8 expose la solution proposée par le pattern Multicast. La généricité de types est utilisée pour créer un message, un expéditeur et un récepteur abstraits et génériques, à savoir les classes MessageAbstrait et ExpéditeurAbstrait ainsi que l’interface RécepteurAbstrait.

Figure 5-1.8 - Le pattern Multicast appliqué à un système de messages

La classe ExpéditeurAbstrait présente deux fonctionnalités :

Elle est basée sur deux types génériques à savoir TMessage qui est contraint par MessageAbstrait et TRécepteur contraint par RécepteurAbstrait<TMessage>. Ainsi, tout message est forcément une sous-classe de MessageAbstrait...