1 Année master ISI

Notes de Cours
Conception avancée des logiciels

Cours 6
Design Patterns (suite)
(Patrons de conception)
Présenté par
Mr KHELIFA N.
 Pattern commande
Supposons que vous construisez un système
domotique.

Il y a une télécommande programmable qui peut

être utilisée pour faire marcher et arrêter divers
éléments de votre maison comme:
les lumières, la stéréo, la climatisation, etc.
 Une télécommande programmable
Il y a des interrupteurs
« marche » et «
arrêt» pour chacun des
sept emplacements.
Nous avons sept
emplacements à
programmer.
Nous pouvons affecter
un appareil différent et
le commander avec les
boutons Ces deux boutons servent
à contrôler l’appareil
ménager mémorisé à
l’emplacement 1...
Classe domotique
 Une solution intuitive
On peut utiliser l’instruction:

if (buttonPressed == button1)

lampe.marche()
if (buttonPressed == button2)

lampe.arret()
 Problème

Pas d’interfaces communes.

Lesclasses seront de plus en plus

nombreuses à l’avenir(changement)
 Solution
ilne faut pas que la commande ait besoin de
connaître les détails des classes propriétaires.

lacommande doit savoir comment interpréter les

appuis sur les boutons

mais elle n’a pas besoin de savoir grand-chose en

domotique, ni sur la façon de mettre en marche
un jacuzzi ou autre.
 Commande

on crée « objets de commande » encapsule une

requête ou une invocation d’une méthode (par
exemple allumer une lampe)

on mémorise un objet de commande pour chaque

bouton, quand on appuie sur celui-ci, on demande
à l’objet de commande d’effectuer un certain
travail
 Commande
Problème
On veut effectuer des requêtes sur des objets sans
avoir à connaître leur structure ou le destinataire de
la demande.
 Commande
 Fonctionnement
Client crée les instances de ConcreteCommand
Un Receiver exécute les commandes
Des ConcreteCommand appellent chaque méthode métier du Receiver
(délègue l’exécution à Receiver)
Une Command décrit l’interface des ConcreteCommand
Un Invoker stocke les instances de ConcreteCommand pour pouvoir les
appeler de manière standardisée
 À un moment donné, il La méthode
demande à la commande de
executer() invoque
satisfaire une requête en
Le Client est responsable de créer une
appelant sa sur le récepteur
CommandeConcrete la ou les actions
méthode executer().
et de définir son Recepteur nécessaires pour
satisfaire la
requête.

Le Récepteur sait comment La CommandeConcrete définit une liaison entre

effectuer le travail nécessaire pour une action et un Récepteur. L’Invocateur émet une
répondre à la requête. N’importe requête en appelant executer() et la
quelle classe peut jouer le rôle de CommandeConcrete y répond en appelant une ou
Récepteur. plusieurs actions sur le Récepteur
Exemple
 Médiateur
 Quand les objets d'un ensemble dialoguent de façon bien définie, mais très
complexe. Le
résultat des interdépendances est non-structuré et difficile à appréhender.
 Quand la réutilisation d'un objet est très difficile, du fait qu'il fait référence
à beaucoup d'autres objets et communique avec eux.
 Quand le contrôle d'exécution d'un ensemble d'objet doit être centralisé.
 Médiateur
 Solution
- Créer un objet qui organise la communication entre un ensemble d'objets.

 Les composants de ce pattern sont:

- Médiator : définit une interface pour communiquer avec les collègues.
- ConcreteMediator : réalise le comportement coopératif en coordonnant les objets
Collègue. Il connaît et gère ses collègues.
- Colleague : chaque classe Collègue connaît son objet Médiateur. Chaque Collègue
s'adresse à son médiateur et n'a pas besoin de connaître les collègues concernés.
Médiateur
Médiateur
 Etat
Problème
- Quand le comportement de l’objet dépend de son état, et
que ce changement de comportement doit intervenir
dynamiquement en fonction de cet état.
- Ce qui varie : la nature des services rendus par un objet en
fonction de son état.
 Etat
 Fonctionnement
Une interface (State) définit le comportement
Des ConcreteState implémentent les comportements
Un Context stocke l’état courant et appelle les comportements
correspondants
Les ConcreteState peuvent changer l’état courant dans le contexte
 Exemple

Soit les états d’un distributeur de bonbons, ou l’états « Pas de pièce » l’état initial du
distributeur et l’utilisateur pourrait faire quelque chose d’absurde, par exemple essayer
d’éjecter la pièce quand l’appareil est dans l’état « Pas de pièce » ou encore insérer deux
pièces.
Etat
 Strategy
 Problème
 (i) définir une famille d’algorithmes,
 (ii) encapsuler chacun et les rendre interchangeables tout en assurant que
chaque algorithme peut évoluer indépendamment des clients qui l’utilisent
- On souhaite que la sélection d’un algorithme dépende du client à
l’origine de la demande.
- Ce qui varie : l'algorithme implémentant un service.
Strategy
 Fonctionnement
 Désencapsuler les comportements de la classe mère de l’objet
 Les déporter dans des classes liées, à l’aide d’une interface commune
 Permettre au client d’utiliser une implémentation quelconque de cette
interface
 Utiliser un contexte qui gère les changements d’implémentation
Exemple
Une application de jeu de simulation sur
les canards
Les canards nagent et crient: :
Solution
 Visitor
 Problème
 Des opérations doivent être réalisées dans une structure d’objets comportant des
objets avec des interfaces différentes
 Comment séparer un algorithme d'une structure de données. Un visiteur possède une
méthode par type d'objet traité.
 La classe définissant la structure change rarement mais de nouvelles opérations
doivent pouvoir être définies souvent sur cette structure
 Visitor
 Fonctionnement
Ajout aux classes de fonctions « virtuelles » génériques qui
redirigent les opérations vers une classe spécifique « Visiteur »
Cette classe redirige les opérations vers les bonnes
implémentations
Patron visiteur
 Pattern visiteur
 Chaque classe pouvant être « visitée » doit mettre à disposition une
méthode publique « accepter » prenant comme argument un objet du
type « visiteur ».

 Laméthode « accepter » appellera la méthode « visite » de l'objet du

type « visiteur » avec pour argument l'objet visité.

 De cette manière, un objet visiteur pourra connaître la référence de

l'objet visité et appeler ses méthodes publiques pour obtenir les données
nécessaires au traitement à effectuer (calcul, génération de rapport, etc.).

 Enpratique un visiteur permet d'obtenir le même effet que d'ajouter une

nouvelle méthode virtuelle à un ensemble de classes qui ne le permet
pas.
 Les classes participants

 Visitor : une interface qui déclare une opération accept() pour chaque classe ConcreteElement de la
structure d'objets. Le nom de l'opération et sa signature identifient la classe émettrice de la
requête accept() chez le visiteur. Le visiteur peut ensuite accéder à l'élément
directement, au travers de son interface particulière.

 ConcreteVisitor : le code de chaque opération déclarée de la classe Visitor. Chaque

opération code un fragment de l'algorithme défini pour les classes d'objets qui lui correspondent dans
la structure. Le visiteur concret fournit le contexte pour l'algorithme et mémorise son état.

 Element : une interface qui définit une opération accept() ayant pour argument un visiteur.

 ConcreteElement : réalise le codage d'une opération accept() qui prend pour

argument un Visitor.

 ObjetStructure : fournit une interface de haut niveau permettant au visiteur de

 visiter ses éléments ; peut être un Composite ou un conteneur tel qu'une liste ou un ensemble.
Exemple sans le patron visiteur
Exemple avec le patron visiteur
Adapter
 Adapter
Problème
Utilisation d’une classe existante dont l’interface ne nous
convient pas (convertir l’interface d’une classe en une autre)
Utilisation de plusieurs sous-classes dont l’adaptation des
interfaces est impossible par dérivation ( Object Adapter)
 Adapter
 Fonctionnement
 Insérer un niveau d’indirection qui réalise la conversion
 Adapter de classe
 il n’introduit qu’une nouvelle classe, une indirection vers la classe adaptée n’est pas
nécessaire
 MAIS il ne fonctionnera pas dans le cas où la classe adaptée est racine d’une dérivation
 Adapter d’objet
 il peut fonctionner avec plusieurs classes adaptées
 MAIS il peut difficilement redéfinir des comportements de la classe adaptée
 Exemple
On veut ajouter des dindons à l'application
canards:
 Solution
Créer un adaptateur de dindon vers canard
 Chaine de responsabilité
 Problème
 Comment faire circuler des demandes dans une chaîne de handlers.
 Lorsqu’un handler reçoit une demande, il décide de la traiter et\ou
de l’envoyer au handler suivant de la chaîne.
.
 Chaine de responsabilité
Fonctionnement
Interface commune à tous les handlers
Chaînage des handlers
Chaine de responsabilité
Merci de votre attention