08/12/2010

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

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

1
 08/12/2010

Strategy (2/4)

Patron de comportement

Strategy (3/4)
4

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.

2
 08/12/2010

Patron de comportement

Strategy (4/4)
5

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 »

3
 08/12/2010

Observer(2/3)

Observer(3/3)

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

4
 08/12/2010

Patron de comportement

Command (1/5)
9

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

5
 08/12/2010

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

6
 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

Champs d’application

Défairedes requêtes (undo)

Paramétrer les objets par des actions

Manipuler les requêtes, les exécuter à différents

moments

7
 08/12/2010

Patron de comportement

Visitor (1/7)
15

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)

8
 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

9
 08/12/2010

Patron de comportement

Visitor (5/7)
19

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 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)

10
 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

11
 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

12
 08/12/2010

Exemple(1/2)

Exemple(2/2)

13