Vous êtes sur la page 1sur 98

Design Patterns

Outils pour la Gestion de Projets


Axe ISI - 2007

Gauthier Picard - Design Patterns

Examen ACSI
Amphi 022 : 13h30-15h00

Gauthier Picard - Design Patterns

Sommaire

Introduction
Design Patterns de cration
Design Patterns de structure
Design Patterns de comportement
Usage et synthse
Bibliographie

Introduction

Gauthier Picard - Design Patterns

Objectifs
Modularit
Facilit de gestion (technologie objet)

Cohsion
Degr avec lequel les tches ralises par un seul module
sont fonctionnellement relies
Une forte cohsion est une bonne qualit

Couplage
Degr dinteraction entre les modules dans le systme
Un couplage'lche est une bonne qualit

Rutilisabilit
Bibliothques, frameworks (cadres)
5

Cohsion : "mauvais" exemple


public class GameBoard {
public GamePiece[ ][ ] getState() { }
// Mthode copiant la grille dans un tableau temporaire, rsultat de lappel de la mthode.
public Player isWinner() { }
// vrifie ltat du jeu pour savoir sil existe un gagnant, dont la rfrence est retourne.
// Null est retourn si aucun gagnant.
public boolean isTie() { }
//retourne true si aucun dplacement ne peut tre effectu, false sinon.
public void display () { }
// affichage du contenu du jeu. Espaces blancs affichs pour chacune des
// rfrences nulles.
}

GameBoard est responsable des rgles du jeu et de laffichage

Cohsion : "bon" exemple


public class GameBoard {
public GamePiece[ ][ ] getState() { }
public Player isWinner() { }
public boolean isTie() { }
}
public class BoardDisplay {
public void displayBoard (GameBoard gb) { }
// affichage du contenu du jeu. Espaces blancs affichs pour chacune des
// rfrences nulles.
}

Couplage : exemple
void initArray(int[] iGradeArray, int nStudents) {
int i;
for (i = 0; i < nStudents; i++) {
iGradeArray[i] = 0;
}
}

Couplage entre client


et initArray par le
Paramtre "nStudents"

void initArray(int[ ] iGradeArray) {


int i;
for (i=0; i < iGradeArray.length; i++)
iGradeArray[i] = 0;
}
}

Couplage faible
(et meilleure fiabilit)
au travers de lutilisation
de lattribut "length"
8

Principes de conception (1)


Programmer une interface plus quune implmentation
Utiliser des classes abstraites (interfaces en Java) pour dfinir
des interfaces communes un ensemble de classes
Dclarer les paramtres comme instances de la classe abstraite
plutt que comme instances de classes particulires
Ainsi :
les classes clients ou les objets sont indpendants des classes
des objets quils utilisent aussi longtemps que les objets
respectent linterface quils attendent
les classes clients ou les objets sont indpendants des classes
qui implmentent linterface

Principes de conception (2)


Prfrer la composition dobjet lhritage de classes
Ainsi :
le comportement peut changer en cours dexcution
les classes sont plus focalises sur une tche
rduction des dpendances dimplmentation

10

Dfinition : Pattern
Un patron dcrit la fois un problme qui se produit trs
frquemment dans lenvironnement et larchitecture de la
solution ce problme de telle faon que lon puisse utiliser
cette solution des milliers de fois sans jamais ladapter deux fois
de la mme manire.
C. Alexander

Dcrire avec succs des types de solutions


rcurrentes des problmes communs dans des
types de situations

11

Dfinition : Design Pattern


Coad [Coad92]
Une abstraction dun doublet, triplet ou dun ensemble de classes qui
peut tre rutilis encore et encore pour le dveloppement dapplications

Appleton [Appleton97]
Une rgle tripartite exprimant une relation entre un certain contexte, un
certain problme qui apparat rptitivement dans ce contexte et une
certaine configuration logicielle qui permet la rsolution de ce problme

Aarsten [Aarsten96]
Un groupe dobjets cooprants lis par des relations et des rgles qui
expriment les liens entre un contexte, un problme de conception et sa
solution
Les patrons sont des composants logiques dcrits indpendamment dun langage
donn (solution exprime par des modles semi-formels)
12

Dfinition : Design Pattern (suite)


Documentation dune exprience prouve de conception
Identification et spcification d abstractions qui sont au dessus
du niveau des simples classes, instances
Vocabulaire commun et aide la comprhension de principes
de conception
Moyen de documentation de logiciels
Aide la construction de logiciels rpondant des proprits
prcises, de logiciels complexes et htrognes
Traductions : patrons de conception, schmas de conception

13

Historique
OOPSLA 87
Beck et Cunnimghan
OOPSLA 91, OOPSLA 92
Gamma et al. (GoF)

Design Patterns : Element of Reusable


Object-Oriented Software Gamma 95

PLoP 94
Montebello

Object Models: Strategies, Patterns and


Applications Coad 95
Patterns Languages of Program Design Coplien et
Schmidt 95

EuroPLoP 96
Kloster

Pattern-Oriented Software Architecture: A System of


Patterns Buschmann 96
Analysis Patterns : Reusable Object Model Fowler 97

ChiliPLoP 98
Wickenburg

14

Catgories de Patterns
Architectural Patterns
schmas dorganisation structurelle de logiciels (pipes, filters, brokers,
blackboard, MVC, )

Design Patterns
caractristiques cls dune structure de conception commune plusieurs
applications,
Porte plus limite que les architectural patterns

Idioms ou coding patterns


solution lie un langage particulier

Anti-patterns
mauvaise solution ou comment sortir d une mauvaise solution

Organizational patterns
Schmas dorganisation de tout ce qui entoure le dveloppement dun
logiciel (humains)
15

Catgories de Design Patterns


Cration
Description de la manire dont un objet ou un ensemble dobjets peuvent
tre crs, initialiss, et configurs
Isolation du code relatif la cration, linitialisation afin de rendre
lapplication indpendante de ces aspects

Structure
Description de la manire dont doivent tre connects des objets de
lapplication afin de rendre ces connections indpendantes des volutions
futures de lapplication
Dcouplage de linterface et de limplmentation de classes et dobjets

Comportement
Description de comportements dinteraction entre objets
Gestion des interactions dynamiques entre des classes et des objets
16

Porte des Design Patterns


Porte de Classe
Focalisation sur les relations entre classes et leurs
sous-classes
Rutilisation par hritage

Porte dInstance
Focalisation sur les relations entre les objets
Rutilisation par composition

17

Design Patterns du GoF


(Gamma, Helm, Johnson, Vlissides)
Catgorie
Porte

Classe

Cration

Structure

Comportement

Factory Method

Adapter

Interpreter
Template Method

Objet

Abstract Factory

Adapter

Chain of Responsibility

Builder

Bridge

Command

Prototype

Composite

Iterator

Singleton

Decorator

Mediator

Facade

Memento

Flyweight

Observer

Proxy

State
Strategy
Visitor
18

Prsentation dun Design Pattern


Nom du pattern
utilis pour dcrire le pattern, ses solutions et les consquences en un mot
ou deux

Problme
description des conditions d applications. Explication du problme et de
son contexte

Solution
description des lments (objets, relations, responsabilits, collaboration)
permettant de concevoir la solution au problme ; utilisation de
diagrammes de classes, de squences,
vision statique ET dynamique de la solution

Consquences
description des rsultats (effets induits) de l application du pattern sur le
systme (effets positifs ET ngatifs)

19

Design Patterns de cration

Gauthier Picard - Design Patterns

20

Design Patterns de cration

Rendre le systme indpendant de la manire dont les objets


sont crs, composs et reprsents

Encapsulation de la connaissance des classes concrtes utiliser


Cacher la manire dont les instances sont cres et combines

Permettre dynamiquement ou statiquement de prciser QUOI


(lobjet), QUI (lacteur), COMMENT (la manire) et QUAND (le
moment) de la cration
Deux types de motifs
1. Motifs de cration de classe (utilisation de lhritage) : Factory
2. Motifs de cration dobjets (dlgation de la construction un autre
objet) : AbstractFactory, Builder, Prototype

21

Exemple : Labyrinthe
Framework

Application
22

Exemple : Labyrinthe
class MazeGame {
void Play() {}
public Maze createMaze() {
Maze aMaze = new Maze();
Room r1 = new Room(1);
Room r2 = new Room(2);
Door theDoor = new Door(r1, r2);
aMaze.addRoom(r1);
aMaze.addRoom(r2);
r1.setSide(North, new Wall());
r1.setSide(East, theDoor);
r1.setSide(South, new Wall());
r1.setSide(West, new Wall());
r2.setSide(North, new Wall());
r2.setSide(East, new Wall());
r2.setSide(South, new Wall());
r2.setSide(West, theDoor);
return aMaze;
}
}

class BombedMazeGame extends MazeGame {

public Maze createMaze() {


Maze aMaze = new Maze();
Room r1 = new RoomWithABomb(1);
Room r2 = new RoomWithABomb(2);
Door theDoor = new Door(r1, r2);
aMaze.addRoom(r1);
aMaze.addRoom(r2);
r1.setSide(North, new BombedWall());
r1.setSide(East, theDoor);
r1.setSide(South, new BombedWall());
r1.setSide(West, new BombedWall());
r2.setSide(North, new BombedWall());
r2.setSide(East, new BombedWall());
r2.setSide(South, new BombedWall());
r2.setSide(West, theDoor);
return aMaze;
}
}

23

Factory Method (1)


Problme
ce motif est utiliser dans les situations o existe le besoin
de standardiser le modle architectural pour un ensemble
dapplications, tout en permettant des applications
individuelles de dfinir elles-mmes leurs propres objets
crer

Consquences
+ Elimination du besoin de code spcifique lapplication dans
le code du framework (uniquement linterface du Product)
Multiplication du nombre de classes

24

Factory Method (2)


Solution
Product defines the
interface of objects the
factory method creates
ConcreteProduct
implements Product
interface

FactoryIF declares
the factory method
which returns the
object of type Product
Factory overrides
the factory method to
return an instance of
a ConcreteProduct

25

Exemple : Labyrinthe
class MazeGame {
void Play() {}

class BombedMazeGame extends MazeGame {

public Wall makeWall() {


return new BombedWall();

public Maze createMaze() {


Maze aMaze = makeMaze();
Room r1 = makeRoom(1);

Room r2 = makeRoom(2);
Door theDoor = makeDoor(r1, r2);

public Room makeRoom(int i) {


return new RoomWithABomb(i);

aMaze.addRoom(r1);
aMaze.addRoom(r2);

}
}

r1.setSide(North, makeWall());
r1.setSide(East, theDoor);
r1.setSide(South, makeWall());
r1.setSide(West, makeWall());
r2.setSide(North, makeWall());
r2.setSide(East, makeWall());
r2.setSide(South, makeWall());
r2.setSide(West, theDoor);
return aMaze;
}
}

26

Abstract Factory (1)


Problme
ce motif est utiliser dans les situations o existe le besoin de travailler
avec des familles de produits tout en tant indpendant du type de ces
produits
doit tre configur par une ou plusieurs familles de produits

Consquences
+ Sparation des classes concrtes, des classes clients
les noms des classes produits napparaissent pas dans le code client
Facilite lchange de familles de produits
Favorise la cohrence entre les produits

+ Le processus de cration est clairement isol dans une classe


la mise en place de nouveaux produits dans lAbstractFactory nest pas
aise

Exemple
java.awt.Toolkit
27

Abstract Factory (2)

AbstractFactory declares an interface for


operations that create abstract product objects
ConcreteFactory implements the operations to
create concrete product objects
AbstractProduct declares an interface for a type
of product object
ConcreteProduct
defines a product object to be created by the corresponding concrete factory
implements the AbstractProduct interface
Client uses interfaces declared by AbstractFactory and AbstractProduct classes
28

Exemple : Labyrinthe
class MazeGame {
void Play() {}

class BombedMazeFactory extends MazeFactory {

public Wall makeWall() {


return new BombedWall();

public Maze createMaze(MazeFactory f) {


Maze aMaze = f.makeMaze();
Room r1 = f.makeRoom(1);

Room r2 = f.makeRoom(2);
Door theDoor = f.makeDoor(r1, r2);

public Room makeRoom(int i) {


return new RoomWithABomb(i);

aMaze.addRoom(r1);
aMaze.addRoom(r2);

}
}

r1.setSide(North, f.makeWall());
r1.setSide(East, theDoor);
r1.setSide(South, makeWall());
r1.setSide(West, makeWall());
r2.setSide(North, makeWall());
r2.setSide(East, makeWall());
r2.setSide(South, makeWall());
r2.setSide(West, theDoor);
return aMaze;
}
}

29

Exemple : Labyrinthe + Factory


Framework

Application
30

Builder (1)
Problme
ce motif est intressant utiliser lorsque lalgorithme de cration dun objet
complexe doit tre indpendant des constituants de lobjet et de leurs
relations, ou lorsque diffrentes reprsentations de lobjet construit doivent
tre possibles

Consquences
+ Variation possible de la reprsentation interne dun produit
limplmentation des produits et de leurs composants est cache au Director
Ainsi la construction dun autre objet revient dfinir un nouveau Builder

+ Isolation du code de construction et du code de reprsentation du reste de


lapplication
+ Meilleur contrle du processus de construction

31

Builder (2)

Builder interface for creating parts of a


Product object

Director constructs an object using


Builder Interface

ConcreteBuilder constructs and


assembles parts of the product by
implementing the Builder interface

Product represents the complex object


under construction
32

Builder (3)

33

Prototype (1)
Problme
Le systme doit tre indpendant de la manire dont ses
produits sont crs, composs et reprsents : les classes
instancier sont spcifies au moment de lexcution
La prsence de hirarchies de Factory similaires aux
hirarchies de produits doivent tre vites. Les
combinaisons dinstances sont en nombre limit

Consquences
mmes consquences que Factory et Builder

Exemple
java.lang.Cloneable
34

Prototype (2)

Prototype declares an interface for cloning itself


ConcretePrototype implements an operation for
cloning itself

Client creates a new object by asking


a prototype to clone itself

35

Exemple : Bilan sur le Labyrinthe


Factory : CreateMaze a un objet en paramtre utilis pour crer
les composants du labyrinthe, on peut changer la structure du
labyrinthe en passant un autre paramtre
Builder : CreateMaze a un objet paramtre capable de crer lui
mme un labyrinthe dans sa totalit, il est possible de changer la
structure du labyrinthe en drivant un nouvel objet
FactoryMethod : CreateMaze appelle des fonctions virtuelles au
lieu de constructeurs pour crer les composants du labyrinthe, il
est alors possible de modifier la cration en drivant une
nouvelle classe et en redfinissant ces fonctions virtuelles
Prototype : CreateMaze est paramtr par des composants
prototypiques quil copie et ajoute au labyrinthe, il est possible de
changer la structure du labyrinthe en fournissant dautres
composants
36

Singleton
Problme
avoir une seule instance dune classe et pouvoir
laccder et la manipuler facilement

Solution
une seule classe est ncessaire pour crire ce motif

Consquences
lunicit de linstance est compltement contrle par
la classe elle mme. Ce motif peut facilement tre
tendu pour permettre la cration dun nombre
donn dinstances
37

Singleton (2)
// Only one object of this class can be created
class Singleton {
private static Singleton instance = null;
private Singleton() {
...
}
public static Singleton getInstance() {
if (instance == null)

instance = new Singleton();


return instance;
}
...
}
class Program {
public void aMethod() {
Singleton X = Singleton.getInstance();
}
}

38

Rsum : DP de cration

Le Factory Pattern est utilis pour choisir et retourner une instance d une
classe parmi un nombre de classes similaires selon une donne fournie la
factory
Le Abstract Factory Pattern est utilis pour retourner un groupe de classes
Le Builder Pattern assemble un nombre dobjets pour construire un nouvel
objet, partir des donnes qui lui sont prsentes. Frquemment le choix des
objets assembler est ralis par le biais dune Factory
Le Prototype Pattern copie ou clone une classe existante plutt que de crer
une nouvelle instance lorsque cette opration est coteuse
Le Singleton Pattern est un pattern qui assure quil ny a quune et une seule
instance dun objet et quil est possible davoir un accs global cette instance

39

Design Patterns de structure

Gauthier Picard - Design Patterns

40

Design Patterns de structure


Abstraction de la manire dont les classes et les objets
sont composs pour former des structures plus
importantes.
Deux types de motifs :
Motifs de structure de classes
Utilisation de lhritage pour composer des interfaces et/ou des
implmentations (ex : Adapter).

Motifs de structure dobjets


composition dobjets pour raliser de nouvelles fonctionnalits :
ajouter dun niveau dindirection pour accder un objet
ex : Adapter dobjet, Bridge, Facade, Proxy,
composition rcursive pour organiser un nombre quelconque dobjets
ex : Composite
41

Adapter (1)
Problme
Utilisation dune classe existante dont linterface ne nous convient pas (
convertir linterface dune classe en une autre)
Utilisation de plusieurs sous-classes dont ladaptation des interfaces est
impossible par drivation ( Object Adapter)

Consquences
Adapter de classe
+ il nintroduit quune nouvelle classe, une indirection vers la classe adapte
nest pas ncessaire
MAIS il ne fonctionnera pas dans le cas o la classe adapte est racine dune
drivation

Adapter dobjet
+ il peut fonctionner avec plusieurs classes adaptes
MAIS il peut difficilement redfinir des comportements de la classe adapte
42

Adapter (2)

Target defines the domain-specific interface


that client uses.

Adaptee defines an existing interface that


needs adapting.

Client collaborates with objects conforming


to the Target interface.

Adapter adapts the interface of Adaptee


to the Target interface.

43

Adapter (3)
interface Stack {
void push(Object o);
Object pop();
Object top();
}
/* Liste doublement chane */
class DList {
public void insert (DNode pos, Object o) { ... }
public void remove (DNode pos) { ... }
public void insertHead (Object o) { ... }
public void insertTail (Object o) { ... }
public Object removeHead () { ... }
public Object removeTail () { ... }
public Object getHead () { ... }
public Object getTail () { ... }
}

Comment adapter une liste


doublement chane en une
pile ?

/* Adapt DList class to Stack interface */


class DListImpStack extends DList implements Stack {
public void push(Object o) {
insertTail(o);
}
public Object pop() {
return removeTail();
}
public Object top() {
return getTail();
}
}

44

Bridge (1)
Problme
ce motif est utiliser lorsque lon veut dcoupler
limplmentation de labstraction de telle sorte que
les deux puissent varier indpendamment

Consquences
+ interfaces et implmentations peuvent tre
couples/dcouples lors de lexcution

45

Bridge (2)
Bridge

Abstraction defines the abstractions


interface.

Implementor defines the interface for


implementation classes.

RefinedAbstraction Extends the interface


defined by Abstraction.

ConcreteImplementor implements the


Implementor interface and defines its
concrete implementation.
46

Chain of Responsibility (1)


Problme
plus d'un objet peut traiter une requte et il n'est pas
connu a priori
l'ensemble des objets pouvant traiter une requte est
construit dynamiquement

Consquences
+ couplage rduit
+ flexibilit accrue pour lassignation de responsabilits
aux objets
MAIS la rception nest pas garantie
47

Chain of Responsibility (2)

Handler
defines an interface for handling requests
(optional) implements the successor link

ConcreteHandler
handles requests it is responsible for
can access its successor

Client initiates the request to a


ConcreteHandler object on the chain

48

Composite (1)
Problme
tablir des structures arborescentes entre des objets et les traiter
uniformment

Consquences
+ hirarchies de classes dans lesquelles lajout de nouveaux composants
est simple
+ simplification du client qui na pas se proccuper de lobjet accd
MAIS il est difficile de restreindre et de vrifier le type des composants

Exemple
java.awt.Component
java.awt.Container

49

Composite (2)

Component declares the interface for


objects in the composition

Composite defines behavior for


components having children

Leaf represents leaf objects in the


composition

Client manipulates objects in the


composition through the Component
interface
50

Decorator (1)
Problme
on veut ajouter/supprimer des responsabilits aux
objets en cours de fonctionnement
lhritage est impossible cause du nombre de
combinaisons, ou cause de droits daccs

Consquences
+ plus de fexibilit que lhritage
+ rduction de la taille des classes du haut de la
hirarchie
MAIS beaucoup de petits objets
51

Decorator (2)

Component defines the interface for


objects that can have responsibilities
added to them dynamically

Decorator maintains a reference to a


Component object and defines an
interface that conforms Component

ConcreteComponent defines an
object to which additional
responsibilities can be attached

ConcreteDecorator adds
responsibilities to the component
52

Faade (1)
Problme
ce motif est utiliser pour faciliter laccs un grand
nombre de modules en fournissant une couche
interface

Consquences
+ facilite lutilisation de sous-systmes
+ favorise un couplage faible entre des classes et
lapplication
MAIS des fonctionnalits des classes interfaces
peuvent tre perdues selon la manire dont est
ralise la Faade
53

Faade (2)

Facade
knows which subsystem classes are
responsible for a request
delegates client requests to appropriate
subsystem objects

Subsystem classes
implement subsystem functionality
handle work assigned by the Faade object
have no knowledge of the faade; that is,
keep no references to it

54

Flyweight (1)
Problme
grand nombre dobjet
le cot du stockage est lev
lapplication ne dpend pas de lidentit des objets

Consquences
+ rduction du nombre dinstances
cot dexcution lev
plus dtats par objet

55

Flyweight (2)

Flyweight declares an interface though with


flyweights can receive and act extrinsic state
SharedConcreteFlyweight implements the
Flyweight interface and adds storage for
intrinsic state, if any
UnsharedConcreteFlyweight not all
flyweight subclasses need to be shared

FlyweightFactory creates and manages


flyweight objects
ensures that flyweights are shared properly.
Client maintains a reference to flyweight(s)
computes or stores the extrinsic state of
flyweight(s)

56

Proxy (1)
diteur
Portion visible du document

Course
Objectiv es

Portion invisible

2-2
What Is Rose
CORBA?
2-4
IncludePath
2-5
Project
Properties
2-6
Assign class to
component
2-7
Where is the code
placed?
2-8

proxy
image stocke
dans une base de
donne

57

Proxy (2)
Problme
ce motif est utiliser pour agir par procuration pour
un objet afin de contrler les oprations qui lui sont
appliques
Masquer des problmes daccs (ex : fichier)
Diffrer lexcution doprations coteuses
Contrler les droits daccs

Consquences
+ ajout dun niveau dindirection lors de laccs dun
objet permettant de cacher le fait que lobjet est dans
un autre espace dadressage, nest pas cr,
58

Proxy (3)

Proxy maintains a reference that lets the


proxy access the real subject. Depending
upon the kind of proxy:
Remote proxies implements the
Flyweight interface and adds storage for
intrinsic state, if any
Virtual proxies may cache additional
information about the real subject
Protection proxies check that the caller
has the access permission required to
perform the request

Subject defines the common interface for


RealSubject and Proxy so that a Proxy can be
used anywhere a RealSubject is expected
RealSubject defines the real object that the
proxy represents

59

Design Patterns de comportement

Gauthier Picard - Design Patterns

60

Design Patterns de comportement


Description de structures dobjets ou de classes avec
leurs interactions
Deux types de motifs
Motifs de comportement de classes :
utilisation de lhritage pour rpartir les comportements entre des
classes (ex : Interpreter)

Motifs de comportement dobjets avec lutilisation de


lassociation entre objets :
pour dcrire comment des groupes dobjets cooprent (ex : Mediator)
pour dfinir et maintenir des dpendances entre objets (ex : Observer)
pour encapsuler un comportement dans un objet et dlguer les
requtes dautres objets (ex : Strategy, State, Command)
pour parcourir des structures en appliquant des comportements (ex :
Visitor, Iterator)
61

Command (1)
Problme
on veut effectuer des requtes sur des objets sans
avoir connatre leur structure

Consquences
+ dcouplage entre lobjet qui appelle et celui qui
excute
+ lajout de nouvelles commandes est aise dans la
mesure o la modification de classes existantes nest
pas ncessaire
62

Command (2)

Command declares an interface for executing an

Invoker asks the command to carry out the

operation

request

ConcreteCommand defines a binding between a

Receiver knows how to perform the operations

Receiver object and an action


Client creates a ConcreteCommand object and
sets its receiver

associated with carrying out a request. Any class


may server a Receiver

63

Interpreter (1)
Problme
ce motif est utiliser lorsque lon veut reprsenter la
grammaire dun langage et linterprter, lorsque :
La grammaire est simple
lefficacit nest pas critique

Consquences
+ facilit de changer et dtendre la grammaire
+ limplmentation de la grammaire est simple
MAIS les grammaires complexes sont dures tenir jour

64

Interpreter (2)

AbstractExpression declares an abstract

NonTerminalExpression implements an

Interpret operation that is common to all


nodes in the abstract syntax tree

Interpret operation for nonterminal symbols in


the grammar

TerminalExpression implements an

Context contains info thats global to the

Interpret operation associated with terminal


symbols in the grammar.

interpreter

Client invokes the Interpret operation


65

Iterator (1)
Problme
ce motif est utiliser pour parcourir une collection dlments
sans accder sa structure interne

Consquences
+ des variations dans le parcours dune collection sont
possibles,
+ simplification de linterface de la collection
+ plusieurs parcours simultans de la collection sont possibles

66

Iterator (2)

Iterator
defines an interface for accessing and
traversing elements

ConcreteIterator
implements the Iterator interface
keeps track of the current position in the
traversal of the aggregate

Aggregate
defines an interface for creating an Iterator
object

ConcreteAggregate
implements the Iterator creation interface to
return an instance of the proper
ConcreteIterator
67

Mediator (1)
Problme
Assurer linteraction entre diffrents objets en assurant leur indpendance :
Les interactions entre les objets sont bien dfinies mais conduisent des
interdpendances difficiles comprendre, ou
La rutilisation dun objet est difficile de part ses interactions avec plusieurs
objets

Consquences
+ limitation de la compartimentation : le mdiator contient le comportement
qui serait distribu sinon entre les diffrents objets, indpendance des
"Colleagues"
+ simplification des protocoles (many-to-many one-to-many)
+ abstraction des cooprations entre objets
MAIS centralisation du contrle, complexit possible du Mdiator

68

Mediator (2)

Mediator defines an interface for


communicating with Colleague objects

ConcreteMediator
implements cooperative behavior by
coordinating Colleague objects
knows and maintains its colleagues

Colleague classes
each Colleague class knows its Mediator
object
each colleague communicates with its
mediator whenever it would have otherwise
communicated with another colleague
69

Memento (1)
Problme
on veut sauvegarder ltat ou une partie de ltat dun
objet
sans violer le principe dencapsulation

Consquences
+ garder les limites de lencapsulation
peut-tre coteux en mmoire et en excution

70

Memento (2)

Memento
stores internal state of the Originator object
protects against access by objects other
than the originator
Originator creates a memento containing
a snapshot of its current internal state

Caretaker
is responsible for the mementos
safekeeping
never operates on or examines the contents
of a memento

71

Observer (1)
Problme
on veut assurer la cohrence entre des classes cooprant
entre elles tout en maintenant leur indpendance

Consquences
+ couplage abstrait entre un sujet et un observeur, support pour
la communication par diffusion,
MAIS des mises jour inattendues peuvent survenir, avec
des cots importants.

Exemple
java.util.Observable
java.util.Observer
72

Observer (2)

Subject knows its observers


provides an interface for attaching and
detaching Observer objects
Observer defines an updating interface
for objects that should be notified of
changes in a subject

ConcreteSubject stores state of interest


to ConcreteObserver objects
sends a notification to its observers
when its state changes
ConcreteObserver maintains a reference
to a ConcreteSubject object
73

Observer (3)
import java.util.Observable;
...
public class EventSource extends Observable implements Runnable {
public void run() {
try {
final InputStreamReader isr = new InputStreamReader(System.in);
final BufferedReader br = new BufferedReader(isr);
while (true) {
final String response = br.readLine();
setChanged();
import java.util.Observable;
notifyObservers(response);
import java.util.Observer;
}
} catch (IOException e) {
public class ResponseHandler implements Observer {
e.printStackTrace();
private String resp;
}
}
public void update(Observable obj, Object arg) {
}
if (arg instanceof String) {
resp = (String) arg;
System.out.println("\nReceived Response: "
+ resp);
public class myapp {
}
public static void main(String args[]) {
}
System.out.println("Enter Text >");
}
// cration dun metteur - lit dans stdin
EventSource evSrc = new EventSource();
// cration dun observer
ResponseHandler respHandler = new ResponseHandler();
// inscrire lobserveur chez lmetteur
evSrc.addObserver(respHandler);
// excution du programme
evSrc.run();
}
}

74

State (1)
Problme
ce motif est utiliser lorsque lon veut quun objet
change de comportement lorsque son tat interne
change

Consquences
+ possibilit dajouter ou de retirer des tats et des
transitions de manire simple
+ suppression de traitements conditionnels
+ les transitions entre tats sont rendues explicites
75

State (2)

Context
defines the interface of interest to clients
maintains an instance of a ConcreteState subclass that
defines the current state

ConcreteState subclasses
each subclass implements a behavior
associated with a state of the Context

State
defines a interface for encapsulating the behavior
associated with a particular state of the Context.
76

Strategy (1)
Problme
on veut (i) dfinir une famille dalgorithmes, (ii) encapsuler
chacun et les rendre interchangeables tout en assurant que
chaque algorithme peut voluer indpendamment des clients
qui lutilisent

Consquences
+ Expression hirarchique de familles dalgorithmes, limination
de tests pour slectionner le bon algorithme, laisse un choix
dimplmentation et une slection dynamique de lalgorithme
Les clients doivent faire attention la stratgie, surcot li
la communication entre Strategy et Context, augmentation du
nombre dobjets
77

Strategy (2)

Strategy
declares an interface common to all
supported algorithms
ConcreteStrategy implements the
algorithm using the Strategy interface

Client
is configured with a ConcreteStrategy object
maintains a reference to a Strategy object
may define an interface that lets Strategy access
its data
78

Visitor (1)
Problme
Des oprations doivent tre ralises dans une structure dobjets
comportant des objets avec des interfaces diffrentes
Plusieurs oprations distinctes doivent tre ralises sur des objets dune
structure
La classe dfinissant la structure change rarement mais de nouvelles
oprations doivent pouvoir tre dfinies souvent sur cette structure

Consquences
+ lajout de nouvelles oprations est ais
+ union de diffrentes oprations et sparations dautres
MAIS lajout de nouvelles classes concrtes est freine

79

Visitor (2)

Visitor declares a Visit operation for each class of

ConcreteElement implements an Accept

ConcreteElement in the object structure


ConcreteVisitor implements each operation
declared by Visitor
Element defines an Accept operation that takes a
visitor as an argument

operation that takes a visitor as an argument


ObjectStructure
can enumerate its elements
may provide a high-level interface to allow the
visitor to visit its elements.

80

Visitor (3)

81

Usage et synthse

Gauthier Picard - Design Patterns

82

Model View Controler (1)


Premire version en 1980, VisualWorks, ,
Java AWT,
Le MVC organis en trois types dobjets :
Modle (application, pas d interface utilisateur),
Vue (fentres sur lapplication, maintenant l image
du modle),
Contrleur (ractions de linterface aux actions de
lutilisateur, changement des tats du modle).

flexibilit, rutilisation.
83

Model View Controler (2)


View-View
Composite
Decorator

View-Model
Observer

View-Controler
Strategy
Factory Method

Controler-Model
Command
84

Trouver les bons objets


Les patterns proposent des abstractions qui
n'apparaissent pas "naturellement" en observant
le monde rel
Composite : permet de traiter uniformment une
structure d'objets htrognes
Strategy : permet d'implanter une famille
d'algorithmes interchangeables
State

Ils amliorent la flexibilit et la rutilisabilit


85

Bien choisir la granularit


La taille des objets peut varier considrablement
: comment choisir ce qui doit tre dcompos ou
au contraire regroup ?
Facade
Flyweight
Abstract Factory
Builder

86

Penser interface
Quest-ce qui fait partie dun objet ou non ?
Memento : mmorise les tats, retour arrire
Decorator : augmente l'interface
Proxy : interface dlgue
Visitor : regroupe des interfaces
Facade : cache une structure complexe d'objet

87

Spcifier limplmentation
Diffrence type-classe...
Chain of Responsibility ; mme interface, mais implantations
diffrentes
Composite : les Components ont une mme interface dont
l'implantation est en partie partage dans le Composite
Command, Observer, State, Strategy ne sont souvent que
des interfaces abstraites
Prototype, Singleton, Factory, Builder sont des abstractions
pour crer des objets qui permettent de penser en termes
d'interfaces et de leur associer diffrentes implantations

88

Mieux rutiliser
Hritage vs Composition
white-box reuse : rompt l'encapsulation - stricte ou non
black-box reuse : flexible, dynamique

Prfrez la composition lhritage


Dlgation (redirection)
Une forme de composition qui remplace l'hritage
Bridge dcouple l'interface de l'implantation
Mediator, Visitor, Proxy
89

En bref, les Design Patterns


Cest...
une description dune solution classique un problme
rcurent
une description dune partie de la solution... avec des
relations avec le systme et les autres parties...
une technique darchitecture logicielle

Ce nest pas...
une brique
Un pattern dpend de son environnement

une rgle
Un pattern ne peut pas sappliquer mcaniquement

une mthode
Ne guide pas une prise de dcision : un pattern est la dcision prise
90

Bibliographie

91

Bibliographie

Pattern Languages of Program Design , Coplien J.O., Schmidt D.C., AddisonWesley, 1995.
Pattern languages of program design 2 , Vlissides, et al, ISBN 0-201-89527-7,
Addison-Wesley
Pattern-oriented software architecture, a system of patterns , Buschmann, et al,
Wiley
Advanced C++ Programming Styles and Idioms , Coplien J.O., Addison-Wesley,
1992.
S.R. Alpert, K.Brown, B.Woolf (1998) The Design Patterns Smalltalk Companion,
Addison-Wesley (Software patterns series).
J.W.Cooper (1998), The Design Patterns Java Companion,
http://www.patterndepot.com/put/8/JavaPatterns.htm.
S.A. Stelting, O.Maasen (2002) Applied Java Patterns, Sun Microsystems Press.
Communications of ACM, October 1997, vol. 40 (10).
Thinking in Patterns with Java http://mindview.net/Books/TIPatterns/

92

Quelques sites Web


http://hillside.net/
Portland Pattern Repository
http://www.c2.com/ppr

A Learning Guide To Design Patterns


http://www.industriallogic.com/papers/learning.html

Vince Huston
http://home.earthlink.net/~huston2/

Ward Cunnigham's WikiWiki Web


http://www.c2.com/cgi/wiki?WelcomeVisitors

Core J2EE Patterns


http://www.corej2eepatterns.com/index.htm
93

Composite : Exercice
Chacun des membres de la compagnie reoit un
salaire.
A tout moment, il doit tre possible de demander le
cot dun employ.
Le cot dun employ est calcul par :
Le cot dun individu
est son salaire.
Le cot dun responsable
est son salaire plus
celui de ses subordonns.

94

Observer : Exercice (1)


Counter : peut crotre ou dcrotre dune unit. A chaque fois
que le Counter change de valeur, il notifie ses observers du
changement.
CounterButton : classe abstraite, permettant de changer la
valeur dun Counter
IncreaseButton (resp. DecreaseButton) fait crotre (resp.
dcrotre) la valeur de Counter auquel il est attach chaque
fois que press
CounterView : vue observant un Counter. Utilise comme
Parent pour dautres vues.
CounterTextView : affichage de la valeur dun compteur en
Ascii (sous classe de CounterView)

95

Observer : Exercice (2)


ButtonControler : fentre pour changer la valeur dun
Counter en utilisant les boutons (sous classe de
CounterView)
RectangleView : attach deux Counters (un pour la
largeur et un autre pour la hauteur) (sous classe de
CounterView)
Dvelopper:
IncreaseDetector (resp. DecreaseDetector) : affect un ou
plusieurs Counter, compte le nombre de fois que leurs valeurs
crot (resp. dcrot). Il notifie ses observers des
changements.

96

Observer : Exercice (3)


Observable

Frame
Interface
Observer
CounterView

Counter
RectangleView

IncreaseDetector
DecreaseDetector

Button

ButtonController

CounterButton

IncreaseButton

CounterTextView

DecreaseButton
97

Observer : Exercice (4)


Counter x = new Counter( "x" );
Counter y = new Counter( "y" );
IncreaseDetector plus = new IncreaseDetector( "Plus" );
DecreaseDetector moins = new DecreaseDetector( "Moins" )
x.addObserver( plus );
x.addObserver( moins );
y.addObserver( plus );
y.addObserver( moins );
new ButtonController( x, 30, 30, 150, 50 );
new ButtonController( y, 30, 100, 150, 50 );
new CounterTextView( plus, "CounterTextView # of increases",
30, 170, 150, 50);
new CounterTextView( moins, "CounterTextView # of decreases",
30, 170, 150, 50);
new RectangleView( x, y, 340, 30 );
98