Design Pattern

1
Design Pattern

• à partir dun cours de Philippe Collet

2
Patrons de création

• Comment un objet peut être créé
• Indépendance entre la manière de créer et la
  manière dutiliser

3
Singleton (1/4)
Patron de conception
Patron de structure
Patron de comportement

• Intention
• Sassurer quune classe a une seule instance, et
  fournir un point daccès global à celle-ci.
• Exemple
• Un seul window manager, un seul point daccès à
  une base de donnée, etc.
• Plus puissant que la variable globale
• Champs dapplication
• Lorsque linstance unique doit être extensible
  par héritage, et que les clients doivent pouvoir
  utiliser cette instance étendue sans modifier
  leur code

4
Singleton (2/4)
Patron de conception
Patron de structure
Patron de comportement

• Structure
• un champs static uniqueInstance
• une méthode static instance() retourne
  uniqueInstance
• un constructeur protected (héritage)
• le client ne peut accéder à linstance quà
  travers la méthode spécifique (instance())

5
Singleton (3/4)
Patron de conception
Patron de structure
Patron de comportement

• Conséquences
• Accès contrôlé
• Pas de variable globale
• Permet la spécialisation des opérations et de la
  représentation
• Permet un nombre variable dinstances (compteur,
  tableau dans le singleton)

6
Singleton (4/4)
Patron de conception
Patron de structure
Patron de comportement

• Implémentation
• Assurer lunicité
• Sous-classer (demander quelle forme de singleton
  dans la méthode instance() )
• Utilisations connues
• DefaultToolkit en AWT/Java java.awt.DefaultToolk
  it.getDefaultToolkit()

7
Factory - Factory Method (1/5)
Patron de conception
Patron de structure
Patron de comportement

• Intention
• Définit une classe pour la création dun objet,
  mais en laissant à des sous-classes le choix des
  classes à instancier
• Permet la délégation dinstanciation
• Exemple
• Instancier des classes, en connaissant uniquement
  les classes abstraites
• fabrique de bébêtes encapsulée, simplification
  déquation (paramètre)
• Synonyme constructeur virtuel

8
Factory Method (2/5)
Patron de conception
Patron de structure
Patron de comportement

• Champs dapplication
• une classe ne peut pas anticiper lobjet quelle
  doit construire (utiliser)
• une classe délègue la responsabilité de la
  création à ses sousclasses, tout en concentrant
  l'interface dans une classe unique

9
Factory Method (3/5)
Patron de conception
Patron de structure
Patron de comportement

• Structure
• Objet à créer
• Une interface (ou classe abstraite) Product
• définit linterface des objets créés par la
  fabrication
• Une ou plusieurs classes concrètes
  ConcreteProduct
• implémente linterface Product
• Createur
• Une classe abstraite, Creator
• déclare la fabrication celle-ci renvoie un objet
  de type Product. Le Creator peut également
  définir une implémentation par défaut de la
  fabrication, qui renvoie un objet ConcreteProduct
  par défaut. Il peut appeler la fabrication pour
  créer un objet Product.
• public abstract Product FactoryMethod()
• Une ou plusieurs classes concrètes
  ConcreteCreator, qui retournent des
  ConcreteProduct

10
Factory Method (4/5)
Patron de conception
Patron de structure
Patron de comportement

• Conséquence
• La fabrication dispense davoir à incorporer à
  son code des classes spécifiques de
  lapplication. Le code ne concerne que
  linterface Product, il peut donc fonctionner
  avec toute classe ConcreteProduct définie par
  lutilisateur
• La création dobjets à lintérieur dune classe
  avec la méthode fabrication est toujours plus
  flexible que la création dun objet directement

11
Factory Method (5/5)
Patron de conception
Patron de structure
Patron de comportement

• Implémentation (2 possibilités)
• La classe Creator est une classe abstraite et ne
  fournit pas dimplémentation
• La classe Creator est une classe concrète qui
  fournit une implémentation par défaut pour la
  fabrication
• Fabrication paramétrée
• Utilisation de paramètres pour déterminer la
  variété dobjet
• Exemple fabrique de plante de couleur, choix
  dobjet en fonction de dimensions, etc.

12
Abstract Factory (1/7)
Patron de conception
Patron de structure
Patron de comportement

• Intention
• Fournir une interface pour créer des familles
  dobjets dépendants ou associés sans connaître
  leur classe réelle
• Fabriquer des fabriques.
• Exemple
• Génération décosystème pour les bébêtes
• Une fabrique à jardin
• Synonymes Kit, Fabrique abstraite, Usine
  abstraite

13
Abstract Factory (2/7)
Patron de conception
Patron de structure
Patron de comportement

• Champs dapplication
• Indépendance de comment les objets/produits sont
  créés, composés et représentés
• Configuration dun système par une instance dune
  multitude de familles de produits
• Conception dune famille dobjets pour être
  utilisés ensemble et contrôle de cette contrainte
• Bibliothèque fournie avec seulement leurs
  interfaces, pas leurs implémentations(bibilothèqu
  e graphique, look-and-feel)

14
Abstract Factory (3/7)
Patron de conception
Patron de structure
Patron de comportement
15
Abstract Factory (4/7)
Patron de conception
Patron de structure
Patron de comportement

• Structure
• La fabrique
• AbstractFactory déclare linterface pour les
  opérations qui créent des objets abstraits
• ConcreteFactory implémente les opérations qui
  crée les objets concrets
• Les objets (plusieurs types)
• AbstractProduct déclare une interface pour un
  type dobjet
• ConcreteProduct définit un objet qui doit être
  créé par la fabrique concrète correspondante et
  implémente linterface AbstractProduct
• Lutilisateur
• Client utilise seulement les interfaces déclarée
  par AbstractFactory et par les classes
  AbstractProduct

16
Abstract Factory (5/7)
Patron de conception
Patron de structure
Patron de comportement

• Collaborations
• Normalement, une seule instance de fabrique
  concrète est créée à lexécution. Cette fabrique
  crée les objets avec une implémentation
  spécifique. Pour créer différents sortes
  dobjets, les clients doivent utiliser
  différentes fabriques concrètes.
• La fabrique abstraite défère la création des
  objets à ses sous-classes concrètes

17
Abstract Factory (6/7)
Patron de conception
Patron de structure
Patron de comportement

• Conséquences
• Isolation des classes concrètes (seules les
  classes abstraites sont connues)
• Échange facile des familles de produit
• Encouragement de la cohérence entre les produits
• Prise en compte difficile de nouvelles formes de
  produit

18
Abstract Factory (7/7)
Patron de conception
Patron de structure
Patron de comportement

• Implémentation
• Les fabriques sont souvent des singletons
• Ce sont les sous-classes concrètes qui font la
  création, en utilisant le plus souvent une
  Factory Method
• Si plusieurs familles sont possibles, la fabrique
  concrète utilise Prototype

19
Builder
Patron de conception
Patron de structure
Patron de comportement

• Intention
• Séparer la construction dun objet complexe de sa
  représentation, de sorte que le même processus de
  construction adapte la représentation selon les
  objets
• Exemple
• Dans un carnet dadresse, traiter de la même
  façon les personnes et les groupes
• Manipuler ensemble des objets  proches  (cf
  générateur dinterface)
• Structure
• Une classe abstraite Representation pour définir
  les différents types de représentation
• Le builder regroupe des objets à représenter
• Le builder utilise une fabrique (qui retourne des
  classes concrètes étendant Representation) en
  fonction des objets
• Conséquences
• La représentations internes dun objet peut
  varier.
• La modularité les builders sont indépendants

20
Prototype
Patron de conception
Patron de structure
Patron de comportement

• Intention
• Dupliquer (cloner) un objet trop coûteux à créer
• Créer des objets différents uniquement par le
  comportement. Le prototype sert de modèle.
• Exemple
• Objet représentant une grosse base de données
• Duplication de bébêtes (sans en connaître le
  type)
• Structure
• Méthode deepClone (clone est une méthode
  protected)
• Utilisation de la sérialisation (lire un flux
  dans lequel on écrit lobjet à dupliquer)
• Conséquences
• Création dinstances  différentes  sans créer
  de classe
• Difficultés duplication (Serializable ?) accès
  aux données ?

21
Patron de structure

• Comment les objets peuvent être combinés
• Indépendance entre les objets et les connexions

22
Adapter (1/4)
Patron de structure
Patron de conception
Patron de comportement

• Intention
• Convertir linterface dune classe en une autre
  interface qui est attendue par un client.
• Permet de faire collaborer des classes qui
  nauraient pas pu le faire à cause de
  lincompatibilité de leurs interfaces
• Exemple
• Une classe de bibliothèque conçue pour la
  réutilisation ne peut pas lêtre à cause dune
  demande spécifique de lapplication
• Les Adapter de java MouseAdapter,
  WindowAdapter,etc.
• Synonymes Wrapper, Mariage de convenance

23
Adapter (2/4)
Patron de structure
Patron de conception
Patron de comportement

• Structure
• Une cible (Target) définit linterface spécifique
  à lapplication que le client utilise
• Le Client collabore avec les objets qui sont
  conformes à linterface de Target
• La classe à adapter (Adaptee) est linterface
  existante qui a besoin dadaptation
• Ladaptateur (Adapter) adapte effectivement
  linterface de Adaptee à linterface de Target
  par traduction des accès (appels de méthode)

24
Adapter (3/4)
Patron de structure
Patron de conception
Patron de comportement

• Conséquences
• Pour la classe de lobjet qui adapte
• Pas possible dadapter une classe et ses
  sous-classes
• Mais redéfinition possible du comportement
  (sous-classe)
• Pour lobjet qui adapte
• Un adapter peut travailler avec plusieurs
  Adaptees
• Plus difficile de redéfinir le comportement
  dAdaptee (sous-classer puis obliger Adapter a
  référencer la sousclasse)

25
Adapter (4/4)
Patron de structure
Patron de conception
Patron de comportement

• Implémentation
• Par héritage (multiple) de la classe à adapter,
  en y ajoutant les méthodes de linterface cible
  et en assurant les appels adéquats aux méthodes
  de la classe à adapter
• Par composition, selon le même principe (faire
  correspondre les appels de méthode) sauf que la
  classe à adapter est un champ de la classe qui
  adapte

26
Decorator (1/5)
Patron de conception
Patron de comportement
Patron de structure

• Intention
• Attacher dynamiquement des capacités
  additionnelles à un objet
• Fournir ainsi une alternative flexible à
  lhéritage pour étendre les fonctionnalités
• Exemple
• Ajout de capacités pour objet individuellement et
  dynamiquement
• Englober lobjet existant dans un autre objet qui
  ajoute les capacités (plus que dhériter)
• ex JScrollPane
• Synonyme Wrapper (attention !)

27
Decorator (2/5)
Patron de structure
Patron de conception
Patron de comportement

• Champs dapplication
• Pour ajouter des capacités de manière
  transparente
• Pour des capacités qui peuvent être retirées
• Quand lextension par héritage produirait un
  nombre trop important dextensions indépendantes
• Quand lhéritage est interdit

28
Decorator (3/5)
Patron de structure
Patron de conception
Patron de comportement
29
Decorator (4/5)
Patron de structure
Patron de conception
Patron de comportement

• Structure
• Component définit linterface des objets qui
  peuvent avoir des capacités dynamiques
• ConcreteComponent définit lobjet auquel on peut
  attacher de nouvelles capacités
• Decorator maintient une référence à lobjet
  Component et définit une interface conforme à ce
  même Component
• ConcreteDecorator ajoute les capacités à
  component (implémente les fonctions déclarées
  dans Decorator)
• Decorator transmets les demandes à son objet
  Component. Il peut aussi effectuer du travail en
  plus avant et après la transmission

30
Decorator (5/5)
Patron de structure
Patron de conception
Patron de comportement

• Implémentation
• Java utilisation dinterface pour la conformité
• Pas forcément besoin dun décorateur abstrait
• Maintenir une classe de base légère
• Decorator est fait pour le changement daspect,
  Strategy est fait pour le changement radical
  dapproche
• Conséquences
• Personnalisation dobjets sans héritage
• Perte de type (perte de la relation  est-un )
• Multiplication des classes (les décorations)

31
Façade (1/5)
Patron de structure
Patron de conception
Patron de comportement

• Intention
• Fournir une interface unique, simplifiée ou
  unifiée, pour accéder à un ensemble dinterfaces
  dun sous-système complexe.
• Exemple
• Réduire la complexité dun système en le
  découpant en plusieurs sous-systèmes ET éviter la
  dépendance entre les clients et les éléments du
  sous-système
• Principe des entrepôts de données
• Couplage dune interface avec un  noyau
  fonctionnel 

32
Façade (2/5)
Patron de structure
Patron de conception
Patron de comportement

• Champs dapplication
• Fournir une interface unique pour un système
  complexe
• Séparer un sous-système de ses clients
• Découper un système en couches (une façade par
  point dentrée dans chaque couche)

33
Façade (3/5)
Patron de structure
Patron de conception
Patron de comportement

• Structure
• La Façade connaît quelles classes du sous-système
  sont responsables de telle ou telle requête, et
  délègue donc les requêtes aux objets appropriés
• Les classes sous-jacentes à la façade
  implémentent les fonctionnalités
• Le nombre de classes nest pas limité
• Les clients manipulent le sous-système en
  sadressant à la façade (ou aux éléments du
  sous-système rendus publics par la façade)
• La façade transmet les requêtes au sous-système
  après transformation si nécessaire

34
Façade (4/5)
Patron de structure
Patron de conception
Patron de comportement

• Conséquences
• Facilite lutilisation par la simplification de
  linterface
• Diminue le couplage entre le client et le
  sous-système
• Ne masque pas forcément les éléments du
  sous-système (un client peut utiliser la façade
  ou le sous-système)
• Permet de modifier les classes du sous-système
  sans affecter le client
• Peut masquer les éléments privés du sous-système
• Linterface unifiée présentée par la façade peut
  être trop restrictive

35
Façade (5/5)
Patron de structure
Patron de conception
Patron de comportement

• Implémentation
• Possibilité de réduire encore plus le couplage en
  créant une façade abstraite et des versions
  concrètes
• Les objets de façade sont souvent des singletons
• Possibilité de Façade dans les deux sens
  devient un Mediator

36
Composite (1/5)
Patron de structure
Patron de conception
Patron de comportement

• Intention
• Composer des objets dans des structures darbre
  pour représenter des hiérarchies
  composants/composés
• Composite permet au client de manipuler
  uniformément les objets simples et les objets au
  sein de leurs compositions
• Exemple
• Structure hiérarchiques dune entreprise
  techniciens, cadres (employé)
• JComponent / JButton, JLabel, etc. ou
  java.awt.Component / java.awt.Container

37
Composite (2/5)
Patron de structure
Patron de conception
Patron de comportement

• Champs dapplication
• Une classe abstraite qui représente à la fois les
  primitives (contenues) et les containers
• Représentation de hiérarchie composants /
  composés
• Les clients doivent ignorer la différence entre
  les objets simples et leurs compositions
  (uniformité apparente)

38
Composite (3/5)
Patron de structure
Patron de conception
Patron de comportement
39
Composite (4/5)
Patron de structure
Patron de conception
Patron de comportement

• Structure
• Component (java.awt.Component)
• déclare linterface commune à tous les objets
• implémente le comportement par défaut pour toutes
  les classes si nécessaire
• déclare linterface pour gérer les composants
  fils
• Définit linterface pour accéder au composant
  parent (optionnel)
• Leaf représente une feuille (java.awt.Button)
• Implémentation du comportement
• Composite (java.awt.Container) définit le
  comportement des composants ayant des fils,
  stocke les fils et implémente les opérations
  nécessaires à leur gestion
• Lien dans la hiérarchie
• Comportement fusion des comportements des fils
• Les clients (affichage graphique) utilise
  linterface Component, si le receveur est une
  feuille la requête est directement traitée, sinon
  le Composite retransmet habituellement la requête
  à ses fils en effectuant éventuellement des
  traitements supplémentaires avant et/ou après

40
Composite (5/5)
Patron de structure
Patron de conception
Patron de comportement

• Conséquence
• Structure hiérarchique, simple, uniforme, général
  et facile à étendre pour de nouveaux objets
• Implémentation
• Maximiser linterface de Component
• Déclaration des opérations de gestion des fils
• Ordonnancement des fils gt Iterator
• Optionnel Référence explicite aux parents

41
Proxy (1/5)
Patron de structure
Patron de conception
Patron de comportement

• Intention
• Fournir un substitut afin daccéder à un autre
  objet souvent inaccessible.
• Séparer linterface de limplémentation
• Exemple
• Si un objet, comme une image volumineuse, met
  beaucoup de temps à se charger
• Si un objet est situé sur une machine distante
• Si un objet a des droits daccès spécifiques (les
  fournir aux utilisateurs)
• Synonyme Procuration, mandat, surrogate

42
Proxy (2/5)
Patron de structure
Patron de conception
Patron de comportement

• Champs dapplication
• Dès quil y a un besoin de référencement
  sophistiqué ou polyvalent, autre quun simple
  pointeur
• Remote Proxy est un représentant dun objet situé
  dans un autre espace dadressage
• Virtual Proxy crée des objets coûteux à la
  demande
• Access Proxy contrôle laccès à un objet
• SmartReference effectue un travail supplémentaire
  lors de laccès à lobjet
• Comptage de références (smart pointers)
• Chargement dobjets persistants
• Vérification de non verrouillage

43
Proxy (3/5)
Patron de structure
Patron de conception
Patron de comportement

• Structure
• Subject (interface dutilisation de lobjet à
  représenter) définit une interface commune pour
  RealSubject et Proxy. Proxy peut ainsi être
  utilisé partout où le RealSubject devrait être
  utilisé
• Proxy maintient une référence qui permet au Proxy
  daccéder au RealSubject. Il fournit une
  interface identique à celle de Subject, pour
  pouvoir se substituer au RealSubject. Il contrôle
  les accès au RealSubject
• RealSubject définit lobjet réel que le Proxy
  représente
• Le Proxy retransmet les requêtes au RealSubject
  lorsque cest nécessaire, selon la forme du Proxy

44
Proxy (4/5)
Patron de conception
Patron de comportement
Patron de structure
aRealSubjectSubject
aProxy Proxy
aClient Client
45
Proxy (5/5)
Patron de structure
Patron de conception
Patron de comportement

• Conséquence
• Linaccessibilité du sujet est transparente
• Comme le proxy a la même interface que son sujet,
  ils peuvent être librement interchangeable
• le proxy nest pas un objet réel mais simplement
  la réplique exacte de son sujet
• Possibilité doptimisation (chargement par
  tranche par exemple)

46
Bridge
Patron de structure
Patron de conception
Patron de comportement

• Intention
• Découple labstraction (interface) de
  limplémentation afin de permettre aux deux de
  varier indépendamment
• Partager une implémentation entre de multiples
  objets
• Exemple
• MVC, PAC découplage entre les facettes
  (interfaces de communications)
• Permet de développer des représentations
  interchangeables
• Structure
• Programmation par deux interfaces
• Conséquence
• Modularité, indépendance, réutilisation
• Masquer les détails dun côté à lautre

47
Flyweight
Patron de structure
Patron de conception
Patron de comportement

• Intention
• Limiter le nombre dinstance en factorisant des
  données en dehors des classes
• Exemple
• Comportement des bébêtes un seul comportement
  pour plusieurs bébêtes
• Bébêtes elles-mêmes une seule bébête et
  ChampDeBebetes qui fournit les coordonnées,
  vitesses et orientation
• Structure
• Distinction entre état intrinsèque et état
  extrinsèque
• déterminer où et comment stocker les données
• Regroupement des données extrinsèques
• Un seul objet permet dobtenir le comportement de
  beaucoup dautre (paramétrage des méthodes avec
  les données extrinsèques)

48
Patrons de comportement

• Comment les objets communiquent
• Encapsulation de processus

49
Command (1/5)
Patron de comportement
Patron de structure
Patron de conception

• Intention
• Encapsuler une requête comme un objet
• Permettre de défaire des traitements (undo)
• Exemple
• Découpler les objets qui invoquent une action de
  ceux qui lexécutent
• Réaliser un traitement sans avoir besoin de
  savoir de quoi il sagit et de qui va leffectuer
• Exemple événements graphiques
• Éviter les tests imbriqués dans le traitement des
  événements
• Synonymes Action, Transaction

50
Command (2/5)
Patron de comportement
Patron de structure
Patron de conception
51
Command (3/5)
Patron de comportement
Patron de structure
Patron de conception

• Structure
• Command déclare une interface pour exécuter une
  opération
• ConcreteCommand définit une astreinte entre
  lobjet Receiver et laction concrétisé execute()
  en invoquant la méthode correspondante de lobjet
  Receiver
• Client crée lobjet ConcreteCommand et positionne
  son Receiver
• Invoker demande à lobjet Command dentreprendre
  la requête
• Receiver sait comment effectuer la ou les
  opérations associées à la demande
• Déroulement
• Un Client crée une Command puis demande la prise
  en compte de la commande par linvoker
• Linvoker appel execute, la Command réalise
  laction sur le Receiver

52
Command (4/5)
Patron de comportement
Patron de structure
Patron de conception

• Champs dapplication
• Défaire des requêtes (undo)
• Paramétrer les objets par des actions
• Manipuler les requêtes, les exécuter à différents
  moments

53
Command (5/5)
Patron de comportement
Patron de structure
Patron de conception

• Conséquences
• Découplage entre invocation et réalisation
• Commandes manipulées comme nimporte quel autre
  objet
• Facilité dajouts de nouvelles commandes
• Implémentation
• Pour supporter les undo et redo, il faut définir
  les opérations correspondantes et la classe
  ConcreteCommand doit stocker, pour cela,
  certaines informations (état initiale ou comment
  défaire)
• Un historique des commandes doit être conservé
  pour réaliser les undo à plusieurs niveaux

54
Template Template Method (1/3)
Patron de comportement
Patron de structure
Patron de conception

• Intention
• Définir le squelette dun algorithme dans une
  opération, et laisser les sous-classes définir
  certaines étapes
• Permet de redéfinir des parties de l'algorithme
  sans avoir à modifier celui-ci
• Exemple
• Faire varier le comportement de chaque opération
  de façon indépendante dans les sous-classes
• BebeteAbstraite et vos BebeteConcrete
• Swing AbstractButton et JButton, JMenuItem,
  JToggleButton
• Champs dapplication
• Implanter une partie invariante dun algorithme
• Partager des comportements communs dune
  hiérarchie de classes

55
Template (2/3)
Patron de comportement
Patron de structure
Patron de conception

• Structure
• AbstractTemplate définit les opérations
  primitives abstraites implémentées par les
  sous-classes concrètes, implémente un template
  method définissant la trame dun algorithme
• ConcreteTemplate implémente les opérations
  primitives pour exécuter les étapes spécifiques
  de lalgorithme
• Conséquences
• Réutilisation du code
• Structure de contrôle inversé (la classe concrète
  ne définit que les méthodes dont elle a besoin)
• Permet dimposer des règles de surcharge
• Mais il faut sous-classer pour spécialiser le
  comportement

56
Template (3/3)
Patron de comportement
Patron de structure
Patron de conception

• Implémentation 4 types de méthode
• Méthodes concrètes dans la classe abstraite,
  surcharge non prévues
• Méthodes abstraites
• Méthodes avec un comportement par défaut pouvant
  être surchargées
• Template Methods des méthodes faisant une suite
  dappel aux trois types précédents, surcharge non
  prévues

57
State (1/3)
Patron de comportement
Patron de structure
Patron de conception

• Intention
• Modifier le comportement dun objet quand son
  état interne change
• Obtenir des traitements en fonction de l'état
  courant
• Tout est mis en place pour donner limpression
  que lobjet lui même a été modifié
• Exemple
• Éviter les instructions conditionnelles de grande
  taille (if then else)
• Simplifier lajout et la suppression dun état et
  le comportement qui lui est associé
• Comportement des bébêtes avec mémoire de la
  position, de la vitesse et de la direction
  (intelligence) avec décision de lévolution de
  létat
• État dun connexion réseau (recherche, établie,
  interrompue, fermée)
• Champs dapplication
• Implanter une partie invariante dun algorithme
• Partager des comportements communs dune
  hiérarchie de classes

58
State (2/3)
Patron de comportement
Patron de structure
Patron de conception
59
State (3/3)
Patron de comportement
Patron de structure
Patron de conception

• Structure
• Context est une classe qui permet dutiliser un
  objet à état et qui gère une instance dun objet
  ConcreteState
• State définit une interface qui encapsule le
  comportement associé avec un état particulier de
  Context
• Les ConcretState implémentent un comportement
  associé avec létat de Context
• Il revient soit à Context, soit aux ConcreteState
  de décider de létat qui succède à un autre état
• Conséquences
• Séparation des comportements relatifs à chaque
  état
• transitions plus explicites
• Implémentation
• Déléguer des opérations dépendantes des états de
  lobjet Contexte à son objet état actuel
• Veiller à ce que lobjet Contexte pointe sur un
  objet état qui reflète son état actuel

60
Strategy (1/4)
Patron de comportement
Patron de structure
Patron de conception

• Intention
• Définir une hiérarchie de classes pour une
  famille d'algorithmes, encapsuler chacun d'eux,
  et les rendre interchangeables
• Les algorithmes varient indépendamment des
  clients qui les utilisent
• Exemple
• Cas des classes ayant le même comportement et
  utilisant des variantes dun même algorithme
  Encapsuler ces algorithmes dans une classe (la
  stratégie)
• Implémenter les stratégies dans les classes
  héritées
• Évite les répétitions de code
• LayoutManager en awt / swing
• Comportement des bébêtes (contrôlées par un
  élément extérieur aux bébêtes)
• Synonyme Policy

61
Strategy (2/4)
Patron de comportement
Patron de structure
Patron de conception

• Champs dapplication
• Lorsque de nombreuses classes associées ne
  diffèrent que par leur comportement
• Lorsquon a besoin de plusieurs variantes dun
  algorithme
• Lorsquun algorithme utilise des données que les
  clients ne doivent pas connaître
• Lorsquune classe définit plusieurs comportements

62
Strategy (3/4)
Patron de comportement
Patron de structure
Patron de conception

• Structure
• Context maintient une référence à lobjet
  Strategy. Il peut définir un interface qui permet
  à lobjet Strategy daccéder à ses données
• Strategy déclare une interface commune à tous les
  algorithmes
• ConcreteStrategy implémente lalgorithme en
  utilisant linterface Strategy
• Déroulement
• Le Context envoie les requêtes de ses clients à
  lune de ses stratégies.
• Les clients créent la classe concrète qui
  implémente lalgorithme.
• Puis ils passent la classe au Context.
• Enfin ils interagissent avec le Context
  exclusivement.

63
Strategy (4/4)
Patron de comportement
Patron de structure
Patron de conception

• Conséquences positives
• Simplification du code client
• Élimination des boucles conditionnelles
• Extension des algorithmes
• Les clients nont pas besoin davoir accès au
  code des classes concrètes
• Les familles dalgorithmes peuvent être rangées
  hiérarchiquement ou rassemblées dans une
  super-classe commune
• Conséquences négatives
• Le Context ne doit pas changer
• Les clients doivent connaître les différentes
  stratégies
• Le nombre dobjets augmente beaucoup
• Imaginons une classe Strategy avec beaucoup de
  méthodes. Chaque sous-classe connaît ses méthodes
  mais peut être quelle ne les utilisera pas

64
Visitor (1/7)
Patron de comportement
Patron de structure
Patron de conception

• Intention
• Représenter UNE opération à effectuer sur les
  éléments dune structure
• Permet de définir une nouvelle opération sans
  changer les classes des éléments sur lesquels on
  opère
• Exemple
• Un arbre de syntaxe abstraite pour un
  compilateur, un outil XMLDifférents traitement
  sur le même arbre type check, optimisation,
  analyses
• Faire la somme des jours de congés des employés
  dune entreprise
• Recensement des bébêtes

65
Visitor (2/7)
Patron de comportement
Patron de structure
Patron de conception

• Champs dapplication
• Une structure contient beaucoup de classes aux
  interfaces différentes
• Pour éviter la pollution des classes de la
  structure
• Les classes définissant la structure changent
  peu, mais de nouvelles opérations sont toujours
  nécessaires

66
Visitor (3/7)
Patron de comportement
Patron de structure
Patron de conception

• Structure
• ObjectStructure (le programme demandeur) peut
  énumérer ses éléments de type Element et peut
  être un Composite
• Element définit une opération accept qui prend un
  Visitor en paramètre
• ConcreteElement implémente lopération accept

67
Visitor (4/7)
Patron de comportement
Patron de structure
Patron de conception

• Structure
• Visitor
• déclare lopération de visite pour chaque classe
  de ConcreteElement dans la structure
• La signature (et le nom) de lopération identifie
  la classe qui envoie la requête de visite au
  visiteur. Le visiteur détermine alors la classe
  concrète et accède à lélément directement
• ConcreteVisitor
• Implémente chaque opération déclarée par Visitor
• Chaque opération implémente un fragment de
  lalgorithme, et un état local peut être stocké
  pour accumuler les résultats de la traversée de
  la structure

68
Visitor (5/7)
Patron de comportement
Patron de structure
Patron de conception

• Déroulement
• Un objectStructure parcours ses éléments
  (différentiation selon le type possible) et
  envoie le visiteur (elt.accept(visiteur))
• Les éléments appelent (à tour de rôle)
  lopération du visiteur (visiteur.visit(this))
• Le visiteur agrège les données aux travers
  dappel de méthode des éléments (paramètres de
  visit)

69
Visitor (6/7)
Patron de comportement
Patron de structure
Patron de conception

• Conséquences
• Ajout de nouvelles opérations très facile
• Groupement/séparation des opérations communes
• Ajout de nouveaux ConcreteElement complexe
  (opération dépendant du type)
• Visitor traverse des structures où les éléments
  sont de types complètement différents / Iterator
• Accumulation détat dans le visiteur plutôt que
  dans des arguments
• Suppose que linterface de ConcreteElement est
  assez riche pour que le visiteur fasse son
  travail gt cela force à montrer létat interne et
  à casser lencapsulation

70
Visitor (7/7)
Patron de comportement
Patron de structure
Patron de conception

• Implémentation
• Visitor Double dispatch nom de lopération
  2 receveurs visiteur élément
• Cest la clé du pattern Visitor
• Single dispatch (C, Java) 2 critères pour une
  opération nom de lopération type du receveur
• Pour la traversée des objets repose sur une liste
  (itérator)
• Soit conservée par lObjetStructure
• Soit conservée par le visiteur

71
Chain of Responsibility
Patron de comportement
Patron de structure
Patron de conception

• Intention
• Permettre à des classes de manipuler une requête
  sans connaître le rôle des autres classes
• Fournir un couplage souple entre les instances
  une requête non traitée et passée au suivant
• Exemple
• Quand une requête peut concerner plusieurs
  éléments sans savoir lequel
• Exemple une commande et le path
• Structure
• Une interface avec des méthodes du type
  addChain (ajoute un suivant), sendToChain(param)
  transmettre le message et getChain() obtenir
  le suivant
• Construction de la chaîne par ce qui crée les
  éléments de la chaîne.
• Si aucun traitement, alors la requête est
   oubliée  par le dernier élément
• Conséquence
• Réduction du couplage entre les éléments de la
  chaîne
• Flexibilité dans la distribution des
  responsabilité
• Interface (préserver le extends) obligation
  dimplémenter des méthodes

72
Interpreter
Patron de comportement
Patron de structure
Patron de conception

• Intention
• Définir un langage (grammaire) et lutiliser pour
  commander (interpréter) le programme
• Exemple
• Quand le programme doit analyser une chaîne
  algébrique (évaluation déquation)
• Interaction (plusieurs sorties) via des requêtes
  (genre sql) permet une interaction clavier et
  automatique
• Macro (VBA)
• Structure
• Un parser analyse les verbes et les variables
  (expression régulière)
• Éxécution en fonction des éléments trouvés
• Conséquence
• Souplesse dans les requêtes
• Difficulté dans les requêtes (fautes
  dorthographe)

73
Mediator
Patron de comportement
Patron de structure
Patron de conception

• Intention
• Simplifier la structure dun ensemble dobjets
• Limiter la dépendance des objets en introduisant
  un Mediator qui assure le lien entre tous
• Exemple
• Tout programme avec des dépendances
• Le C de PAC les facettes présentation et
  abstraction ne se connaissent pas
• Structure
• Chaque objet est construit avec un référence sur
  le Mediator (avec un enregistrement auprès du
  Mediator méthode mediator.register(this))
• Le mediator concentre les liens entre les objets
  méthodes spécialisées ou génériques (message)
• Conséquence
• Couplage souple entre les objets (connaissance du
  seul Mediator)
• Comportement du groupe concentré dans le Mediator
  modifiabilité
• Ajout délément dans le groupe facilité (seul le
  Mediator le connaît)
• Mais le Mediator peut  exploser 

74
Mediator, exercice

• Une liste de produit
• celection par champ de texte
• ou par choix dans la liste
• Initialement
• buy (actif) et clear (grisé)
• caddie vide
• Ajout de remove
• Ajout du total
• Comparaison sans Mediator vs avec

buy
remove
clear
Total _______
75
Memento
Patron de comportement
Patron de structure
Patron de conception

• Intention
• Mécanisme de sauvegarde et de restauration
  dobjet sans que cela soit prévu
• Structure
• Lélément original à sauver
• Le Memento celui qui sauvegarde et restaure
• Problème daccès au champ de lélément à
  sauvegarder
• Méthodes save et restore
• La Reflexivité ou la Serialization peuvent être
  une solution
• Le Synchroniseur celui qui déclenche

76
Les deux derniers
Patron de comportement
Patron de structure
Patron de conception

• Iterator les  container  java (Iterator,
  ArrayList, etc.)
• Observer