1 6.Patrons de conception : le distributeur de pizzas Cette séance de TP a pour objectif d'introduire l'emploi des patrons de conception (design pattern) dans le cadre de la programmation en Java. Les patrons étudiés au cours de cette séance de laboratoire sont : le patron composite (Composite pattern), le patron fabrique abstraite (Abstract Factory pattern), le patron singleton (Singleton pattern), le patron état (State pattern) et le patron décorateur (Decorator pattern). Les patrons de conception ne sont pas liés à un langage de programmation. Ils peuvent être implémentés dans n'importe quel langage tant que celui-ci prend en compte les notions d'orienté objet, d'héritage et d'interface. 6.1.Patrons de conception a) Le patron composite Illustration 1: Diagramme de classe du patron de conception composite L'illustration 1 présente le diagramme de classe du patron de conception composite. Il contient une interface répertoriant l'ensemble des opérations qui sont implémentées à la fois par les «feuilles» et par l'objet composite. Cette interface permet de manipuler les feuilles ou l'objet composite de la même manière. Les feuilles fournissent donc une implémentation aux diverses méthodes de l'interface. L'objet composite contient une liste de feuilles et fournit des méthodes supplémentaires qui permettent de gérer cette liste (ajout, retrait et récupération d'éléments). Les opérations dans l'objet composite font généralement appel aux opérations de même nom pour chaque feuille présente dans la liste et agrègent les résultats que ces feuilles renvoient. Par exemple, le prix d'un harmonica serait la somme du prix de ses composants (capot, plancher, hanches ). b)le patron fabrique abstraite (Abstract Factory) Ce patron utilise le patron fabrique. La fabrique crée et retourne des objets qui dérivent d'une même classe abstraite. L'appelant ne connaîtra donc pas le type exact de l'objet. La fabrique abstraite regroupe plusieurs fabriques et peut remplir plusieurs rôles. Dans un premier contexte, les fabriques permettent de construire des objets dérivant de différents type abstraits. A chaque type abstrait serait associé une fabrique et les types abstraits se partagent une interface commune. A nouveau, le rôle serait ici de masquer le type spécifique des objets créés afin de simplifier la programmation. Dans un second contexte, présenté dans l'illustration 2, les fabriques ne sont pas associées à un type abstrait en particulier, mais à certaines classes dérivées d'un ou plusieurs types abstraits. Par exemple, dans un système d'exploitation fournissant plusieurs thèmes graphiques, une fabrique de composants graphiques peut être associée à chaque thème. Chaque fabrique renvoie ainsi des boutons, des fenêtres et autres dont les
2 fonctionnalités ne changent pas d'une fabrique à l'autre, mais dont le style graphique dépend du thème associé à la fabrique. Illustration 2: Diagramme de classe du patron de conception fabrique abstraite c) Le patron singleton Illustration 3: Diagramme de classe du patron de conception Singleton L'Illustration 3 présente le diagramme de classe du patron singleton. Ce patron permet de garantir qu'il n'existera qu'une seule instance de la classe singleton au sein d'un programme. Pour ce faire, un pointeur statique du même type que la classe singleton est ajouté en son sein et le constructeur est rendu privé. Une méthode publique et statique est alors utilisée pour créer et renvoyer l'instance de la classe. Lors de son premier appel, cette méthode instancie la classe, place l'adresse de cette unique instance dans le pointeur statique de la classe et la renvoie à l'appelant. A tout autre appel, la méthode ne fait que renvoyer la référence contenue dans le pointeur statique. d)le patron état (State) Le patron de conception état permet d'implémenter un système qui passe d'un état à un autre (de type «machine à état») et dont le comportement dépend de l'état dans lequel il se trouve. Dans l'exemple d'un distributeur de billets, on peut imaginer une opération «retrait d'argent» qui, lorsque le distributeur est dans un état «normal», permet à l'utilisateur le retrait de son argent. Dans le cas où le distributeur arrive à cours de billets, son état est alors changé en «Retrait indisponible» et lorsque l'utilisateur fait appel à la fonctionnalité «retrait d'argent», un message d'erreur lui est communiqué pour lui indiquer l'absence de billets et l'impossibilité d'accomplir l'opération. Le diagramme de ce patron de conception est présenté à l'illustration 4. La classe Context est la classe qui doit utiliser une fonctionnalité dépendant de l'état du système. Cette classe contient une
3 instance de State, qui est l'interface définissant les méthodes dont l'exécution dépend de l'état du système. Chaque état du système sera donc représenté par une implémentation différente de l'interface State. Ces différents états sont inter-changés au sein de la classe Context. Ainsi, lorsque l'appelant communique une requête, comme «retrait d'argent», à Context, la réponse à cette requête dépend directement de l'état du système. Illustration 4: Diagramme de classe du patron de conception état e) Le patron décorateur (Decorator) Ce patron de conception permet d'attacher de nouvelles fonctionnalités à un objet sans changer le comportement des autres objets du même type. Ce patron est présenté à l'illustration 5. Le décorateur et l'élément à décorer doivent implémenter la même interface, Component dans l'exemple. Cette interface permet de spécifier les opérations qui seront modifiées par le décorateur. Le décorateur est une classe abstraite qui contient une instance de la classe qui sera «décorée». Les classes concrètes qui héritent du décorateur peuvent implémenter différemment les opérations de l'interface Component. Ainsi, lorsqu'un nouvel objet Component doit être construit, soit on renvoie directement une instance de ConcreteComponent, adoptant ainsi le comportement standard de la classe, soit on renvoie une instance de ConcreteDecorator qui redéfinit ainsi les opérations de la classe ConcreteComponent. Par exemple, dans le cas d'un concessionnaire de voiture, on peut imaginer une interface Voiture qui fournit entre autres une méthode qui permet d'obtenir le prix d'une voiture. Il est alors possible de créer des décorateurs pour équiper la voiture d'options. Il peut ainsi y avoir le décorateur VoitureAvecToitOuvrant qui modifie la fonction getprix() en renvoyant le prix standard de la voiture incrémenté de 5000. Illustration 5: Diagramme de classe du patron de conception décorateur.
4 6.2.Énoncé Il vous est demandé de concevoir un programme qui simule le comportement simplifié d'un distributeur de pizza. Les pizzas sont composées des aliments suivants : pâte (3 ), sauce tomate (1,50 ), crème blanche (1,50 ), fromage (2 ), champignons (1 ), fruits de mer (2,50 ), jambon (2 ), olives (1 ). Les différentes pizzas disponibles sont : Margherita : pâte, sauce tomate, fromage. Prosciutto : pâte, sauce tomate, fromage, jambon. Frutti di mare : pâte, sauce tomate, fromage, fruits de mer. Carbonara : pâte, crème blanche, fromage, jambon. Il vous est demandé d'utiliser le patron de conception composite pour implémenter les pizzas et leurs aliments. Les pizzas peuvent venir de deux fast-foods différents : du Pizza Hut ou du Domino Pizza. Les pizza du Pizza Hut sont similaires à celles du Domino Pizza, mais elle contiennent aussi des olives. Il vous est demandé d'utiliser le patron de conception fabrique abstraite pour construire les pizza du Domino Pizza et du Pizza Hut. Les fabriques peuvent fabriquer au maximum 2 pizzas de chaque sorte. Il vous est demandé d'implémenter les fabriques à l'aide du patron de conception singleton afin qu'il n'existe qu'une seule instance de chaque fabrique au sein du système. Indépendamment de leur fast-food d'origine, la pâte des pizzas peut être «décorée». La pâte «cheesy crust» augmente le prix de la pizza de 2 et change son nom en «Cheesy + 'nom de la pizza'». La pâte «pan» augmente le prix de la pizza de 1,50 et change son nom en «Pan + 'nom de la pizza'». Il vous est demandé d'employer le patron de conception décorateur pour implémenter cette fonctionnalité. Enfin, les distributeurs de pizza connaissent deux états. A un distributeur est assigné une fabrique. Dans son état initial, «en service», le distributeur fournit les pizzas normalement. Lorsqu'un client (la classe de test) cherche à commander une nouvelle pizza alors que le stock est vide, l'état du distributeur change pour l'état «hors service». Dans cet état, les distributeurs cessent de délivrer des pizzas et affiche un message d'état indisponible. Il ne vous est pas demandé d'implémenter le réapprovisionnement des distributeurs. Le changement d'état des distributeurs doit être implémenté en suivant l'architecture du patron de conception état. Votre classe de test devra : implémenter un distributeur de pizza Pizza Hut et un distributeur de pizza Domino ; commander à chacun de ces distributeurs 3 pizzas margherita (une standard, une pan pizza et une cheezy pizza) ; afficher le nom, la composition et le prix de chacune des pizzas commandées. 6.1.Bibliographie 1. JAVA - Comment programmer Quatrième édition, Harvey M. Deitel & Paul J. Deitel Les éditions Reynald Goulet INC., 2002 2. Méthodologie et Langages de Programmation, Pierre Manneback, Année académique 2005-2006. 3. Wikipedia - Diagrame de classe UML pour le patron de conception composite https://upload.wikimedia.org/wikipedia/commons/e/e9/composite_uml_class_diagram_ fr.svg?uselang=fr 4. Wiki Minetti - Design pattern:fabrique abstraite -
5 http://www.minetti.org/wiki/design_pattern:fabrique_abstraite 5. Crunchify - Thread-Safe and a Fast Singleton Implementation Singleton Design Pattern in java - http://crunchify.com/thread-safe-and-a-fast-singleton-implementation-in-java/ 6. Wikipedia - État (patron de conception) - https://fr.wikipedia.org/wiki/%c3%89tat_ %28patron_de_conception%29 7. Wikipedia Décorateur (patron de conception) https://upload.wikimedia.org/wikipedia/commons/e/e9/decorator_uml_class_diagram.s vg