designpattern desc + exemple

8/6/2019 DesignPattern Desc + Exemple

1/40

1

Les design patterns

A. Beugnard 1999

A. Beu nard ENST Breta ne

1Les design patterns

Design Pattern

Objectifs

Comprendre les bases de la philosophie des formes deconception

Connatre le vocabulaire spcifique

Connatre quelques patterns

Concevoir objet diffremment

A. Beugnard ENST Bretagne


Design Pattern

En architecture (Christopher Alexander) Description d'un problme rmanent et de sa

solution Solution pouvant tre utilise des millions de fois

sans tre deux fois identique

Forme de conception, pattern, modle, patron deconception

Mur, porte, fentre objet, interface, classe

Il existe aussi des anti-patterns


2/40

2

Les design patterns

A. Beugnard 1999



Ce que c est

Description d une solution classique un problmercurent

Dcrit une partie de la solution Avec des relations avec le systme et les autres

parties...

C est une technique d architecture logicielle



Ce que ce n est pas

Une brique Un pattern dpend de son environnement

Une rgle Un pattern ne peut pas s appliquer mcaniquement

Une mthode Ne guide pas une prise de dcision ; un pattern est la

dcision prise

Nouveau Lao-Tzu (-550) travaillait dj sur les patterns...

Computer scientists think they have discovered the world Anonymous


3/40

3

Les design patterns

A. Beugnard 1999



Avantages

Un vocabulaire commun Capitalisation de l exprience

Un niveau d abstraction plus lev qui permetd laborer des constructions logicielles de meilleurequalit

Rduire la complexit Guide/catalogue de solutions



Inconvnients

Effort de synthse ; reconnatre, abstraire

Apprentissage, exprience

Les patterns se dissolvent en tant utiliss

Nombreux lesquels sont identiques ? De niveaux diffrents des patterns s appuient sur

d autres...


4/40

4

Les design patterns

A. Beugnard 1999



Description dune forme : langage de pattern nom : augmente le vocabulaire, rifie une ide de

solution, permet de mieux communiquer.

problme : quand appliquer la forme, le contexte...

solution : les lments de la solution, leurs relations,

responsabilits, collaborations. Pas de manireprcise, mais suggestives...

consquences : rsultats et compromis issus del'application de la forme



Exemple

Nom Problme

Solution

Consquences

Exemples

Salle d attenteOn doit attendre

Toujours relaxante et pas confine

Attente active ou passive ? Dure del attente ? Distraction ?

Aroport, dentiste, ...


5/40

5

Les design patterns

A. Beugnard 1999



Forme et langage

Une forme est indpendante du langage

(plutt orient-objet, mais pas exclusivement, cf.Patterns dans Minix)

Mais certaines constructions syntaxiques ouproprits du langage rendent inutile ou "naturelle"l'utilisation de telle ou telle forme

(ex : multi-methode simplifie les visiteurs)



Interactions Formes-langages

Influence des langages sur les Patterns des langages implantent des formes de bas niveau quelques formes utilisent des concepts spcifiques un

langage

quelques formes ne sont pas indpendantes des langages certains langages forcent tordre des formes compliques

lors de l implantation

Influence des Patterns sur les langages Les Formes capitalisent l tat de rflexion courant sur les

pratiques de programmation.


6/40

6

Les design patterns

A. Beugnard 1999



Gamma, Helm, Johnson, Vlissides "Design Patterns"

Nom et classification Implantation Intention Exemple de code Autres noms connus Usages connus Motivation (scnario) Formes associes Applicabilit

Structure (OMT) Participants (classes) Collaborations Consquences

La BIBLE

Gang4



Classification

Crateurs Structuraux Comportementaux

Class Factory Method Adapter(class) InterpreterTemplate Method

Object Abstract Factory Adapter(objet) Chain of Respons.Builder Bridge CommandPrototype Composite IteratorSingleton Decorator Mediator

Facade MementoFlyweight ObserverProxy State

StrategyVisitor


7/40

7

Les design patterns

A. Beugnard 1999



Application des formes lors de la conception Trouver les bons objets Bien choisir la granularit des objets Spcifier les interfaces des objets Spcifier l'implantation des objets Mieux rutiliser

hritage vs composition dlgation

Compiled-Time vs Run-Time Structures Concevoir pour l'volution



Mais dabord, le catalogue !

Crational Patterns

Structural Patterns

Behavioural Patterns


8/40

8

Les design patterns

A. Beugnard 1999



Remarque

La rfrence "Design Patterns" dcrit les formes pardes diagrammes OMT... Comme dans la suite

MAIS

L'hritage et les objets ne sont pas ncessaires



Creational Patterns

Formes de cration : Abstraire le processus d'instanciation. Rendre indpendant de la faon dont les objets sont

crs, composs, assembls, reprsents. Encapsuler la connaissance de la classe concrte quiinstancie.

Cacher ce qui est cr, qui cre, comment et quand.


9/40

9

Les design patterns

A. Beugnard 1999



Principes

AbstractFactory ; on passe un paramtre la crationqui dfinit ce qu'on va crer

Builder ; on passe en paramtre un objet qui saitconstruire l'objet partir d'une description

FactoryMethod ; la classe sollicit appelle desmthode abstraites ...il suffit de sous-classer

Prototype ; des prototypes varis existent qui sontcopis et assembls Singleton ; unique instance



Utilisation

On utilise l'AbstractFactory lorsque : un systme doit tre indpendant de la faon dont

ses produits sont crs, assembls, reprsents un systme repose sur un produit d'une famille de

produits une famille de produits doivent tre utiliss ensemble,

pour renforcer cette contrainte on veut dfinir une interface unique une famille de

produits concrets


10/40

10

Les design patterns

A. Beugnard 1999



Abstract Factory

WidgetFactory

createWindowcreateScrollBar

MotifWidgetFactory


MacWidgetFactory


Window

MacWindow MotifWindow

ScrollBar

MacScrollBar MotifScrollBar

Client

Products

Factory



Utilisation

On utilise le Builder lorsque : l'algorithme pour crer un objet doit tre indpendant

des parties qui le compose et de la faon de lesassembler

le processus de construction permet diffrentesreprsentations de l'objet construit


11/40

11

Les design patterns

A. Beugnard 1999



Builder

Builder

buildPart

ConcreteBuilder

buildPartgetResult

Director

construct

forall objects in structure {

builder -> BuildPart()}

Product

structure



Utilisation

On utilise le FactoryMethod lorsque : une classe ne peut anticiper la classe de l'objet

qu'elle doit construire une classe dlgue la responsabilit de la cration

ses sous-classes, tout en concentrant l'interface dansune classe unique


12/40

12

Les design patterns

A. Beugnard 1999



FactoryMethod

Product

ConcreteProduct

Creator

factoryMethod UneOperation

ConcreteCreator

factoryMethod

produit := factoryMethod

return new ConcreteProduct



Utilisation

On utilise le Prototype lorsque : un systme doit tre indpendant de la faon dont

ses produits sont crs, assembls, reprsents quand la classe n'est connue qu' l'excution pour viter une hirarchie de Factory parallle une

hirarchie de produits


13/40

13

Les design patterns

A. Beugnard 1999



Prototype

Client

Operation

Prototype

clone

ConcretePrototype1

clone

return a copy of self

ConcretePrototype2

clone

return a copy of self

o = prototype.clone



Utilisation

On utilise le Singleton lorsque : il n'y a qu'une unique instance d'une classe et qu'elle

doit tre accessible de manire connue une instance unique peut tre sous-classe et que

les clients peuvent rfrencer cette extension sansavoir modifier leur code


14/40

14

Les design patterns

A. Beugnard 1999



Singleton

Singleton

static Instance...

return soleInstance



Structural Patterns

Formes de structure :

Comment les objets sont assembls

Les patterns sont complmentaires les uns desautres


15/40

15

Les design patterns

A. Beugnard 1999



Principes

Adapter ; rendre un objet conformant un autre Bridge ; pour lier une abstraction une implantation Composite ; bas sur des objets primitifs et

composants Decorator ; ajoute des services un objet Facade ; cache une structure complexe Flyweight ; petits objets destins tre partags Proxy ; un objet en masque un autre



Utilisation

On utilise l'Adapter lorsque on veut utiliser :

une classe existante dont l'interface ne convient pas plusieurs sous-classes mais il est est coteux de

redfinir l'interface de chaque sous-classe en lessous-classant. Un adapter peut adapter l'interface auniveau du parent.

Adaptationconception


16/40

16

Les design patterns

A. Beugnard 1999



Adapter

Client Cible

Request

Adapter

Request methodSpec()

Version hritage multiple

Adapt

methodeSpec.



Adapter

Client Cible

Request

Adapter

Request adapt.methodSpec()

Version composition

Adapt

methodeSpec.

adapt


17/40

17

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Bridge lorsque : on veut viter un lien permanent entre l'abstraction et

l'implantation (ex: l'implantation est choisie l'excution)

l'abstraction et l'implantation sont toutes les deuxsusceptibles d'tre raffines

les modifications subies par l'implantation oul'abstraction ne doivent pas avoir d'impacts sur leclient (pas de recompilation)

Conceptionnouvelle



Bridge

Client Abstraction

Operation

RefinedAbstraction

Implementor

OperImpl1

ConcreteImplA

OperImpl1

imp.operImpl()

imp


18/40

18

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Composite lorsque on veut :

reprsenter une hirarchie d'objets ignorer la diffrence entre un composant simple et un

composant en contenant d'autres. (interfaceuniforme)



Composite

Component

Operationadd

Feuille Composite

Operationadd


19/40

19

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Decorator lorsque :

il faut ajouter des responsabilits dynamiquement etde manire transparente

il existe des responsabilits dont on peut se passer des extensions sont indpendantes et qu'il serait

impraticable d'implanter par sous-classage



Decorator Component

Operation

ConcreteComponent Decorator

Operation

DecoratorA

OperationaddedBehavior

DecoratorB

comp.Operation()

comp

super.Operation()addedBehavior()


20/40

20

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Facade lorsque on veut :

fournir une interface simple un systme complexe introduire une interface pour dcoupler les relations

entre deux systmes complexes construire le systme en couche



Facade

FACADE


21/40

21

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Flyweight lorsque : on utilise beaucoup d'objets, et les cots de sauvegarde sont levs, et l'tat des objets peut tre externalis (extrinsic), et de nombreux groupes d'objets peuvent tre

remplacs par quelques objets partags un fois queles tats sont externaliss, et

l'application ne dpend pas de l'identit des objets



Flyweight

FWFactory

get(key)

Flyweight

Operation

UnsharedFW

Operation

si FW(key) existeretourne FW

sinoncreer un new FWle retourne

Client

SharedFW

Operation


22/40

22

Les design patterns

A. Beugnard 1999



Utilisation

On utilise le Proxy lorsqu'on veut rfrencer un objetpar un moyen plus complexe qu'un pointeur...

remote proxy : ambassadeur protection proxy : contrle d'accs rfrence intelligente

persistence

comptage de rfrence



Proxy

Subject

Operation

Proxy

Operation

realSubject.Operation

Client

RealSubject

Operation

realSubject


23/40

23

Les design patterns

A. Beugnard 1999



Behavioural Patterns

Formes de comportement pour dcrire :

des algorithmes des comportements entre objets des formes de communication entre objet



Principes Chain of Responsibility Command Interpreter Iterator

Mediator Memento Observer State Strategy Template Method Visitor


24/40

24

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Chain of Responsibility lorsque :

plus d'un objet peut traiter une requte, et il n'est pasconnu a priori

l'ensemble des objets pouvant traiter une requte est

construit dynamiquement



Chain of Responsibility

Handler

Operation

Handler2

Operation

Client

Handler1

Operation

successor


25/40

25

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Command lorsque :

spcifier, stocker et excuter des actions desmoments diffrents.

on veut pouvoir "dfaire". Les commandes excutespeuvent tre stockes ainsi que les tats des objets

affects... on veut implanter des transactions ; actions de "haut-niveau".



Command

Command

Execute

ConcreteCommand

Execute

Client

Receiver.

Action

Invoker

receiver


26/40

26

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Interpreter lorsqu'il faut interprter un langageet que :

la grammaire est simple

l'efficacit n'est pas un paramtre critique



Interpreter

Expression

Interpret

NonTerminalExpr.

Interpret

Client

TerminalExpres.

Interpret

Context


27/40

27

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Iterator lorsque : pour accder un objet compos dont on ne veut

pas exposer la structure interne pour offrir plusieurs manires de parcourir une

structure compose pour offrir une interface uniforme pour parcourir

diffrentes structures



Iterator

Iterator

first next

donecurrent

ConcreteIterator

ConcreteAggregate

Aggregate

createIterator

Client


28/40

28

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Mediator lorsque :

quand de nombreux objets doivent communiquerensemble

la rutilisation d'un objet est dlicate car il rfrenceet communique avec de nombreux autres objets



Mediator

Colleague

ConcreteColleague2.ConcreteColleague1.ConcreteMediator

Mediatormediator


29/40

29

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Memento lorsque :

on veut sauvegarder tout ou partie de l'tat d'un objetpour ventuellement pouvoir le restaurer, et

une interface directe pour obtenir l'tat de l'objet

briserait l'encapsulation



Memento

CaretakerMementoOriginator


30/40

30

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Observer lorsque : Une abstraction a plusieurs aspects, dpendant l'un

de l'autre. Encapsuler ces aspects indpendamentpermet de les rutiliser sparment.

Quand le changement d'un objet se rpercute versd'autres.

Quand un objet doit prvenir d'autres objets sanspour autant les connaitre.



Observer

ConcreteSubject

Subject

AttachDetachNotify

ConcreteObserver

Update

Observer

Update

observers

subject

forall observers

o.update

subject.action


31/40

31

Les design patterns

A. Beugnard 1999



Utilisation

On utilise State lorsque :

Le comportement d'un objet dpend de son tat, quichange l'excution

Les oprations sont constitues de partie

conditionnelles de grande taille (case)



State

Context

Request

ConcreteStateB

Handle

State

Handle

state.handle

ConcreteStateA

Handle

state


32/40

32

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Strategy lorsque : de nombreuses classes associes ne diffrent que

par leur comportement. Stratgie offre un moyen deconfigurer une classe avec un comportement parmiplusieurs.

on a besoin de plusieurs variantes d'algorithme.

un algorithme utilise des donnes que les clients nedoivent pas connaitre.



Strategy

Context

Request

ConcreteStrategyB

interfaceAlgo

Strategy

interfaceAlgo

ConcreteStrategyA

interfaceAlgo

strategy


33/40

33

Les design patterns

A. Beugnard 1999



Utilisation

On utilise TemplateMethod :

pour implanter une partie invariante d'un algorithme. pour partager des comportements communs d'une

hirarchie de classes. pour contrler des extensions de sous-classe.



Template Method

ConcreteClass

Templateoperation1operation2

AbstractClass

Templateoperation1operation2

operation1

operation2


34/40

34

Les design patterns

A. Beugnard 1999



Utilisation

On utilise Visitor lorsque :

une structure d'objets contient de nombreusesclasses avec des interfaces diffrentes et on veutappliquer des operations diverses sur ces objets.

les structures sont assez stables, et les opration sur

leurs objets volutives.



Visitor

ConcreteElementB

accept(Visitor v)

Element

accept(Visitor)

ConcreteElementA

accept(Visitor v)

ConcreteVisitorB

visitConcretElementA()

Vistor


ConcreteVisitorA


v.visitConcretElementA(this)


35/40

35

Les design patterns

A. Beugnard 1999



Application des formes lors de la conception Trouver les bons objets Bien choisir la granularit des objets Spcifier les interfaces des objets Spcifier l'implantation des objets Mieux rutiliser

hritage vs composition dlgation

Compiled-Time vs Run-Time Structures Concevoir pour l'volution

BIS



Trouver les bons objets

Les patterns proposent des abstractions quin'apparaissent pas "naturellement" en observant lemonde rel :

Composite : permet de traiter uniformment unestructure d'objets htrognes

Strategy : permet d'implanter une familled'algorithmes interchangeables

State

Ils amliorent la flexibilit et la rutilisabilit


36/40

36

Les design patterns

A. Beugnard 1999



Bien choisir la granularit des objets

La taille des objets peut varier considrablement ;comment choisir ce qui doit tre dcompos ou aucontraire regroup ?

Facade Flyweight

Abstract Factory Builder



Spcifier les interfaces des objets

Quest-ce qui fait partie dun objet ou non ?

Memento ; mmorise les tats, retour arrire Decorator ; augmente l'interface Proxy ; interface dlgu Visitor ; regroupe des interfaces Facade ; cache une structure complexe d'objet


37/40

37

Les design patterns

A. Beugnard 1999



Spcifier l'implantation des objets

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 leComposite

Command, Observer, State, Strategy ne sont souventque des interfaces abstraites Prototype, Singleton, Factory, Builder sont des

abstractions pour crer des objets qui permettent depenser en termes d'interfaces et de leur associerdiffrentes implantations



Mieux rutiliser

hritage vs composition white-box reuse ; rompt l'encapsulation - stricte ou non black-box reuse ; flexible, dynamique

"Prfrez la composition l'hritage"

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


38/40

38

Les design patterns

A. Beugnard 1999



Compiled-Time vs Run-Time Structures Aggrgation

composition, is-part-ofdpendence, dure de vie lie, responsabilitplus stable ~ compiled-time, statique

Connaissance (accointance)lien, associationrelation fugitive, utilisation ponctuelledynamique, run-time



Concevoir pour l'volution (1)

Quelques raisons de "reengineering" : Cration d'un objet en rfrenant sa classe

explicitement...Lien une implantation

particulire...pour viter utilisez AbstractFactory,FactoryMethod, Prototype Dpendance d'une opration spcifique...pour

rendre plus souple utilisez Chain OfResponsibility, Command

Dpendance d'une couche matrielle oulogicielle...AbstractFactory, Bridge


39/40

39

Les design patterns

A. Beugnard 1999




Quelques raisons de "reengineering" : Dpendance d'une implantation...pour rendre

plus souple utilisez AbstractFactory, Bridge,Memento, Proxy

Dpendance d'un algorithmeparticulier...Builder, Iterator, Strategy,TemplateMethod, Strategy

Couplage fort...relcher les relations utilisezAbstractFactory, Bridge, Chain OfResponsibility, Command, Facade, Mediator,Observer




Quelques raisons de "reengineering" : Etendre les fonctionnalits en sous-classant

peut tre couteux (tests, comprhension des

superclasses, etc) utilisez aussi la dlgation, lacomposition...Bridge, Chain Of Responsibility,Composite, Decorator, Observer, Strategy,Proxy

Impossibilit de modifier une classe...absencedu source, trop de rpercussions, voyezAdapter, Decorator, Visitor


40/40

Les design patterns



Autres patterns

Architecture : Couche : systmes en couches (OS, piles OSI)

proche de Facade

Algorithmique distribu : Jeton circulant

Vague de calculs diffusant



Conclusion

Architecture de logiciel

Capitalisation d'expriences dans les Patterns

Une forme se mmorise bien, s'adaptencessairement

Pas rserv aux objets

Comme la prose, on les utilise sans le savoir ! maisquand on en est conscient, on amliore sa rflexion.

designpattern desc + exemple

Documents