Vous êtes sur la page 1sur 13

08/12/2010

Les patterns de comportement - Fournir des solutions pour distribuer les traitements et les algorithmes
Les patterns de comportement - Fournir des solutions pour distribuer les traitements et les algorithmes
Les patterns de comportement - Fournir des solutions pour distribuer les traitements et les algorithmes
Les patterns de comportement - Fournir des solutions pour distribuer les traitements et les algorithmes

Les patterns de comportement

- Fournir des solutions pour distribuer les traitements et les algorithmes entre les objets - Organisent les objet et leurs interactions en spécifiant le flux de contrôle et de traitement au sein d’un système d’objets

Patron de comportement

Strategy (1/4)

2

système d’objets Patron de comportement Strategy (1/4) 2 Intention Définir une hiérarchie de classes pour une

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 d’un 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

08/12/2010

Strategy (2/4)
Strategy (2/4)

Patron de comportement

Strategy (3/4)

4

Strategy (2/4) Patron de comportement Strategy (3/4) 4 Structure Context maintient une référence à l’objet

Structure

Context maintient une référence à l’objet Strategy. Il peut définir un interface qui permet à l’objet Strategy d’accéder à ses données Strategy déclare une interface commune à tous les algorithmes ConcreteStrategy implémente l’algorithme en utilisant l’interface Strategy

Déroulement

Le Context envoie les requêtes de ses clients à l’une de ses stratégies. Les clients créent la classe concrète qui implémente l’algorithme. Puis ils passent la classe au Context. Enfin ils interagissent avec le Context exclusivement.

08/12/2010

Patron de comportement

Strategy (4/4)

5

08/12/2010 Patron de comportement Strategy (4/4) 5 Champs d’application Lorsque de nombreuses classes associées ne

Champs d’application

Lorsque de nombreuses classes associées ne diffèrent que par leur comportement Lorsqu’on a besoin de plusieurs variantes d’un algorithme Lorsqu’un algorithme utilise des données que les clients ne doivent pas connaître Lorsqu’une classe définit plusieurs comportements

 

Observer(1/3)

Motivation

 

Maintenir une cohérence entre des objets en relation, en évitant un couplage trop fort entre ceux-ci qui réduirait leur réutilisation Exemple: un élément graphique doit être mis à jour lorsque les données applicatives qu’il affiche sont modifiées; bien que les classes graphiques et les classes données applicatives travaillent ensemble, elles doivent être indépendantes pour être réutilisables.

Intention

 

Définir une dépendance entre des objets pour que tous ceux qui dépendent d’un objet modifié soient avertis du changement d’état et mis à jour automatiquement

Solution

 

Les objets « observateur » délèguent la responsabilité de contrôle d’un évènement à un objet central, le « sujet »

08/12/2010

Observer(2/3)
Observer(2/3)

Observer(3/3)

08/12/2010 Observer(2/3) Observer(3/3) Participants & Collaborations L’interface Subject permet aux observateurs
08/12/2010 Observer(2/3) Observer(3/3) Participants & Collaborations L’interface Subject permet aux observateurs

Participants & Collaborations

L’interface Subject permet aux observateurs de souscrire à la notification de changement d’état d’un objet (attach/detach). C’est cette interface qui connaît les observateurs, et effectue les notifications vers ceux-ci lorsque la méthode notify est appelée. L’interface Observer permet de mettre à jour l’observateur suite à un changement d’état de l’objet dont il dépend. ConcreteSubject implémente l’interface Subject et mémorise les états d’un objet dont les modifications doivent être notifiées aux objets ConcreteObserver (ici subjectState). L’objet ConcreteOberver implémente l’interface Observer. Il gère une référence sur l’objet ConcreteSubject et mémorise l’état de celui-ci. En retour d’une notification du sujet, il peut interroger le sujet sur son état afin d’y adapter celui qu’il gère (ici observerState

08/12/2010

Patron de comportement

Command (1/5)

9

08/12/2010 Patron de comportement Command (1/5) 9 Intention Encapsuler une requête comme un objet Permettre de

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 l’exécutent

possible parce que l’objet qui émet la requête n’a besoin de ne savoir que comment l’émettre, et non pas de savoir comment la requête va être exécutée

Réaliser un traitement sans avoir besoin de savoir de quoi il s’agit et de qui va l’effectuer

Command (2/5) Structure
Command (2/5)
Structure

08/12/2010

Patron de comportement Command (3/5) 11 Le client crée l’objet ConcreteCommand et spécifie le destinataire.
Patron de comportement
Command (3/5)
11
Le client crée l’objet
ConcreteCommand et spécifie
le destinataire.
L’objet Invoker stoque l’objet
ConcreteCommand.
L’objet Invoker émet une requête
en invoquant “execute” sur la
commande.
Lorsque la commande est réversible,
ConcreteCommand stoque l’état
nécessaire pour revenir dans l’état
précédant l’invocation de
“execute”.
L’objet ConcreteCommand
invoque les opérations du
destinataire pour exécuter la
requête.
Exemple : ToolKit
Exemple : ToolKit

08/12/2010

Command (4/5)

Command

déclare une interface pour exécuter une opération.

ConcreteCommand (PasteCommand, OpenCommand)

Définit une liaison entre l’objet destinataire et l’action Implémente “execute” par l’invocation d’ opérations sur le destinataire.

Client (Application)

Crée un objet ConcreteCommand et assigne son destinataire.

Invoker (MenuItem) Demande à la commande de s’exécuter. Destinataire (Document, Application)

Sait comment exécuter les opérations associées à la requête. N’importe quelle classe peut agir comme destinataire.

Patron de comportement

Command (5/5)

14

comme destinataire . Patron de comportement Command (5/5) 14 Champs d’application Défaire des requêtes (undo)

Champs d’application

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

08/12/2010

Patron de comportement

Visitor (1/7)

15

08/12/2010 Patron de comportement Visitor (1/7) 15 Intention Représenter UNE opération à effectuer sur les éléments

Intention

Représenter UNE opération à effectuer sur les éléments d’une 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 XML…Différents traitement sur le même arbre : type check, optimisation, analyses… Faire la somme des jours de congés des employés d’une entreprise Recensement des bébêtes

Visitor (2/7)
Visitor (2/7)

08/12/2010

 

Patron de comportement

Visitor (3/7)

17

 
 

Champs d’application

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

 

Patron de comportement

Visitor (4/7)

18

 
 

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 l’opération accept

08/12/2010

Patron de comportement

Visitor (5/7)

19

08/12/2010 Patron de comportement Visitor (5/7) 19 Structure Visitor déclare l’opération de visite pour chaque classe

Structure

Visitor

déclare l’opération de visite pour chaque classe de ConcreteElement dans la structure La signature (et le nom) de l’opé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 l’algorithme, et un état local peut être stocké pour accumuler les résultats de la traversée de la structure

Patron de comportement Visitor (6/7) 20 Déroulement Un objectStructure parcours ses éléments (différentiation
Patron de comportement
Visitor (6/7)
20
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) l’opération du visiteur (visiteur.visit(this))
Le visiteur agrège les données aux travers d’appel de méthode des éléments
(paramètres de visit)

08/12/2010

 

Patron de comportement

 

Visitor (7/7)

21

 
 

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 l’interface de ConcreteElement est assez riche pour que le visiteur fasse son travail => cela force à montrer l’état interne et à casser l’encapsulation

 

Patron de comportement

 

State (1/3)

22

 
 

Intention

 

Modifier le comportement d’un objet quand son état interne change Obtenir des traitements en fonction de l'état courant Tout est mis en place pour donner l’impression que l’objet lui même a été modifié

 

Exemple

 

Éviter les instructions conditionnelles de grande taille (if then else) Simplifier l’ajout et la suppression d’un é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 d’un connexion réseau (recherche, établie, interrompue, fermée)

 

Champs d’application

 

Implanter une partie invariante d’un algorithme Partager des comportements communs d’une hiérarchie de classes

08/12/2010

 

Patron de comportement

State (2/3)

23

 
 
 
 

Patron de comportement

State (3/3)

24

 
 

Structure

Context est une classe qui permet d’utiliser un objet à état et qui gère une instance d’un 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

08/12/2010

Exemple(1/2)
Exemple(1/2)
Exemple(2/2)
Exemple(2/2)