1

Rutilisation dans les SI :

patrons de conception

M1 Informatique MIF17 2015-2016

Lionel Mdini

Daprs le cours de Yannick Pri

Universit Claude Bernard Lyon 1

2

Plan

Introduction

Patrons GRASP

Patrons architecturaux

Design patterns

Antipatterns

3

Rutilisation

Constante de la conception doutils en gnral Ex. : je dois fabriquer quelque chose qui permette des

passagers dattendre la fin du voyage sur un bateau. Dois-je tout concevoir depuis zro ?

Que puis-je rutiliser ?

En informatique rutilisation de code

sous la forme de composants acheter / fabriquer

sous la forme de frameworks utiliser en les spcialisant

rutilisation de principes de conception connatre

Ds que des principes se rvlent pertinents abstraction / rutilisation

4

Gnralits sur les patterns

Pattern

solution classique un problme de conception classique dans un contexte donn

Pattern de conception

structure et comportement dune socit de classes

description nomme dun problme et dune solution

avec conseils dapplication

5

Gnralits

Origine dans larchitecture ouvrages de Christopher Alexander (77)

Proprits pragmatisme

solutions existantes et prouves

rcurrence bonnes manires de faire prouves

gnrativit comment et quand appliquer, indpendance au langage

de programmation

mergence la solution globale merge de lapplication dun ensemble

de patrons

6

Types de patrons informatiques

Patrons de conception architecture

conception de systmes

conception interaction de composants

comportement

structure

cration

idiomes de programmation Techniques, styles spcifiques un langage

Patrons danalyse

Patrons dorganisation

(O. Aubert)

7

lments dun patron Nom

vocateur

Concis (un ou deux mots)

Problme Points bloquants que le patron cherche rsoudre

Contexte initial Comment le problme survient

Quand la solution fonctionne

Forces/contraintes Forces et contraintes interagissant au sein du contexte

Dtermination des compromis

(O. Aubert)

8

lments dun patron (suite) Solution

Comment mettre en uvre la solution ?

Point de vue statique (structure) et dynamique (interactions)

Description abstraite lment de conception, relation, responsabilits, collaboration

Variantes de solutions

Contexte rsultant Description du contexte rsultant de lapplication du patron

au contexte initial

Consquences positives et ngatives

Exemples Illustrations simples dapplication du pattern

Applications dans des cas rels

(O. Aubert)

9

lments dun patron (suite et fin)

Justification Raisons fondamentales conduisant lutilisation du patron

Rflexions sur la qualit du patron

Patrons associs Similaires

Possdant des contextes initial ou rsultant proches

Discussion

Avantages, inconvnients

Conseils dapplication / dimplmentation

Variantes

Autres

(O. Aubert)

10

Les patrons sont

Des solutions prouves des problmes rcurrents

Spcifiques au domaine dutilisation

Rien dexceptionnel pour les experts dun domaine

Une forme littraire pour documenter des pratiques

Un vocabulaire partag pour discuter de problmes

Un moyen efficace de rutiliser et partager de

lexprience

(O. Aubert)

11

Les patrons ne sont pas

Limits au domaine informatique

Des ides nouvelles

Des solutions qui nont fonctionn quune seule fois

Des principes abstraits ou des heuristiques

Une panace

(O. Aubert)

12

Plan

Introduction

Patrons GRASP

Patrons architecturaux

Design patterns

Antipatterns

13

Conception pilote par les

responsabilits

Mtaphore communaut dobjets responsables qui

collaborent (cf. humains) dans un projet (rles)

Principe penser lorganisation des composants (logiciels ou

autres) en termes de responsabilits par rapport des rles, au sein de collaborations

Responsabilit abstraction de comportement (contrat, obligation)

par rapport un rle une responsabilit nest pas une mthode

les mthodes sacquittent des responsabilits

14

Deux catgories de responsabilits

pour les objets

Savoir connatre les donnes prives encapsules

connatre les objets connexes

connatre les attributs calculer ou driver

Faire faire quelque chose soi-mme (ex. crer un autre

objet, effectuer un calcul)

dclencher une action dun autre objet

contrler et coordonner les activits dautres objets

15

Exemples (bibliothque)

Savoir

Livre est responsable de la connaissance de son numro ISBN

Abonn est responsable de savoir sil lui reste la possibilit demprunter des livres

Faire

Abonn est responsable de la vrification du retard sur les livres prts

16

GRASP

General Responsability Assignment Software Patterns

Ensemble de patterns gnraux daffectation de responsabilits pour aider la conception oriente-objet raisonner objet de faon mthodique, rationnelle,

explicable

Utile pour lanalyse et la conception ralisation dinteractions avec des objets

Rfrence : Larman 2004

17

9 patterns GRASP

1. Crateur

2. Expert en

information

3. Faible couplage

4. Contrleur

5. Forte cohsion

6. Polymorphisme

7. Fabrication pure

8. Indirection

9. Protection des

variations

18

Expert (GRASP)

Problme

Quel est le principe gnral daffectation des responsabilits aux objets ?

Solution

Affecter la responsabilit lexpert en information

la classe qui possde les informations ncessaires pour sacquitter de la responsabilit

19

Expert : exemple

Bibliothque : qui doit avoir la responsabilit de

connatre le nombre dexemplaires disponibles ?

Livre

ISBN

titre

Exemplaire

Dispo :boolean

Abonn

IDAbonn

0..*

emprunte

20

Expert : exemple

Commencer avec la question

De quelle information a-t-on besoin pour dterminer le nombre dexemplaires disponibles ? Disponibilit de toutes les instances

dexemplaires

Puis

Qui en est responsable ? Livre est lExpert pour cette information

21

Expert : exemple

Livre

ISBN

Titre

getNbExemplairesDispo()

Exemplaire

Dispo :boolean

Abonn

IDAbonn

0..*

emprunte

22

Expert (suite)

Tche complexe Que faire quand laccomplissement dune

responsabilit ncessite de linformation rpartie entre diffrents objets ?

Solution : dcomposer la tche Dterminer des experts partiels

Leur attribuer les responsabilits correspondant aux sous-tches

Faire jouer la collaboration pour raliser la tche globale

23

Expert : exemple (suite)

Livre

ISBN

Titre

getNbExemplairesDispo()

Exemplaire

Dispo :boolean

Abonn

IDAbonn

0..*

emprunte

Bibliothque

getNbLivresEnRayon()

contient

24

Expert : exemple (suite)

Bibliothque

Livres[ ]:Livre

Exemplaire

Dispo :boolean

Livre

ISBN

Titre

n=getNbLivresEnRayon :Bibliothque

Livres[0]:Livre

:Exemplaire

1 n2=getNbExemplaires

1.1 d=getDispo

Livres[1]:Livre :Exemplaire

2 n2=getNbExemplaires

2.1 d=getDispo

:Exemplaire 1.2 d=getDispo

25

Expert : discussion

Modle UML appropri Quel modle UML utiliser pour cette analyse ?

Domaine : classes du monde rel

Conception : classes logicielles

Solution : Si linformation est dans les classes de conception, les

utiliser

Sinon essayer dutiliser le modle du domaine pour crer des classes de conception et dterminer lexpert en information

Diagrammes UML utiles Diagrammes de classes : information encapsule

Diagrammes de communication + diagrammes de classes partiel : tches complexes

26

Expert : discussion

Avantages Conforme aux principes de base en OO

encapsulation

collaboration

Dfinitions de classes lgres, faciles comprendre, maintenir, rutiliser

Comportement distribu entre les classes qui ont linformation ncessaire

Systmes robustes et maintenables

27

Expert : discussion

Le plus utilis de tous les patterns dattribution de responsabilits

Autres noms (AKA - Also Known As) Mettre les responsabilits avec les donnes

Qui sait, fait

Faire soi-mme

Patterns lis (voir plus loin) Faible couplage

Forte cohsion

28

Crateur (GRASP)

Problme Qui doit avoir la responsabilit de crer une nouvelle

instance dune classe donne ?

Solution Affecter la classe B la responsabilit de crer une

instance de la classe A si une - ou plusieurs - de ces conditions est vraie :

B contient ou agrge des objets A

B enregistre des objets A

B utilise troitement des objets A

B a les donnes dinitialisation qui seront transmises aux objets A lors de leur cration

B est un Expert en ce qui concerne la cration de A

29

Crateur : exemple

Bibliothque : qui doit tre responsable de la cration de Pret ?

BasePret contient des Pret : elle doit les crer.

BasePret Pret

date 0..*

Exemplaire

30

Crateur : discussion

Guide pour attribuer une responsabilit pour la cration dobjets une tche trs commune en OO

Finalit : trouver un crateur pour qui il est ncessaire dtre connect aux objets crs favorise le Faible couplage

Moins de dpendances de maintenance, plus dopportunits de rutilisation

Pattern lis Faible couplage

Composite

Fabricant

31

Faible couplage (GRASP)

Problme Comment minimiser les dpendances ?

Comment rduire limpact des changements ?

Comment amliorer la rutilisabilit ?

Solution Affecter les responsabilits des classes de sorte

que le couplage reste faible

Appliquer ce principe lors de lvaluation des solutions possibles

32

Couplage

Dfinition Mesure du degr auquel un lment est li un

autre, en a connaissance ou en dpend

Exemples classiques de couplage de TypeX

vers TypeY dans un langage OO

TypeX a un attribut qui rfre TypeY

TypeX a une mthode qui rfrence TypeY

TypeX est une sous-classe directe ou indirecte de TypeY

TypeY est une interface et TypeX limplmente

33

Faible couplage (suite)

Problmes du couplage fort Un changement dans une classe force changer

toutes ou la plupart des classes lies

Les classes prises isolment sont difficiles comprendre

Rutilisation difficile : lemploi dune classe ncessite celui des classes dont elle dpend

Bnfices du couplage faible Exactement linverse

34

Faible couplage (suite)

Principe gnral

Les classes, trs gnriques et trs rutilisables par nature, doivent avoir un faible couplage

Mise en uvre

dterminer plusieurs possibilits pour laffectation des responsabilits

comparer leurs niveaux de couplage en termes de

Nombre de relations entre les classes

Nombre de paramtres circulant dans lappel des mthodes

Frquence des messages

35

Faible couplage : exemple

:Register :Sale

:Payment

makePayment() 1: makePayment()

1.1. create()

:Register p : Payment

:Sale

makePayment() 1: create()

2: addPayment(p)

Que choisir ?

36

Faible couplage : autre exemple

: GestionPret preter( li: Livre, )

li:Livre

1:isbn=getISBN()

:Pret 2:SetISBN(isbn)

: GestionPret :Pret 1:SetLivre(li )

:Livre

1.1:getISBN()

preter( li: Livre, )

Que choisir ?

Pour lapplication de bibliothque, il faut mettre lISBN dun Exemplaire dans le Prt.

37

Faible couplage : discussion

Un principe garder en tte pour toutes les

dcisions de conception

Ne doit pas tre considr indpendamment

dautres patterns comme Expert et Forte cohsion

en gnral, Expert soutient Faible couplage

Pas de mesure absolue de quand un couplage

est trop fort

Un fort couplage nest pas dramatique avec des lments trs stables

java.util par exemple

38

Faible couplage : discussion (suite)

Cas extrme de faible couplage des objets incohrents, complexes, qui font tout le

travail

des objets isols, non coupls, qui servent stocker les donnes

peu ou pas de communication entre objets

mauvaise conception qui va lencontre des principes OO (collaboration dobjets, forte cohsion)

Bref un couplage modr est ncessaire et normal pour

crer des systmes OO

39

Forte cohsion (GRASP)

Problme : maintenir une complexit grable Comment sassurer que les objets restent

comprhensibles ? faciles grer ?

Comment sassurer au passage que les objets contribuent au faible couplage ?

Solution Attribuer les responsabilits de telle sorte que la

cohsion reste forte

Appliquer ce principe pour valuer les solutions possibles

40

Cohsion

(ou cohsion fonctionnelle)

Dfinition mesure informelle de ltroitesse des liens et de la

spcialisation des responsabilits dun lment (dune classe)

relations fonctionnelles entre les diffrentes oprations effectues par un lment

volume de travail ralis par un lment

Une classe qui est fortement cohsive a des responsabilits troitement lies les unes aux autres neffectue pas un travail gigantesque

Un test dcrire une classe avec une seule phrase

41

Forte cohsion (suite)

Problmes des classes faible cohsion

Elle effectuent

trop de tches

des tches sans lien entre elles

Elles sont

difficiles comprendre

difficiles rutiliser

difficiles maintenir

fragiles, constamment affectes par le changement

Bnfices de la forte cohsion :

42

Forte cohsion : exemple

On dlgue la responsabilit de mettre lISBN au prt

On rend GestionPret partiellement responsable de la mise en place des ISBN

GestionPret sera responsable de beaucoup dautres fonctions

: GestionPret preter( li: Livre, )

li:Livre 1:getISBN()

:Pret 2:setISBN(isbn)

: GestionPret :Pret

1:setLivre (li )

li:Livre

1.1:getISBN()

preter( li: Livre, )

43

Forte cohsion : discussion

Forte cohsion va en gnral de paire avec

Faible couplage

Cest un pattern dvaluation garder en tte pendant toute la conception

Permet lvaluation lment par lment (contrairement Faible couplage)

44

Forte cohsion : discussion

Citations

[Booch] : Il existe une cohsion fonctionnelle quand les lments dun composant (eg. les classes)

travaillent tous ensemble pour fournir un

comportement bien dlimit

[Booch] : la modularit est la proprit dun systme qui a t dcompos en un ensemble de

modules cohsifs et peu coupls

45

Contrleur (GRASP)

Problme Quel est le premier objet au del de lIHM

qui reoit et coordonne (contrle) une opration systme (vnement majeur entrant dans le systme) ?

Solution Affecter cette responsabilit une classe qui

reprsente Soit le systme global, un sous-systme majeur ou un

quipement sur lequel le logiciel sexcute contrleur Faade ou variantes

Soit un scnario de cas dutilisation dans lequel lvnement systme se produit contrleur de CU ou contrleur de session

46

Contrleur (GRASP)

Principes un contrleur est un objet qui ne fait rien

reoit les vnements systme

dlgue aux objets dont la responsabilit est de les traiter

il se limite aux tches de contrle et de coordination vrification de la squence des vnements systme

appel des mthodes ad hoc des autres objets

Rgle dor Les oprations systme des CU sont les messages

initiaux qui parviennent au contrleur dans les diagrammes dinteraction de la couche domaine

47

Contrleur (GRASP)

Mise en uvre

Au cours de la dtermination du comportement du systme (besoins, CU, DSS), les oprations

systme sont dtermines et attribues une

classe gnrale Systme

lanalyse/conception, des classes contrleur sont mises en place pour prendre en charge ces

oprations

48

Contrleur : exemple

Pour la gestion dune bibliothque, qui doit tre contrleur pour lopration systme emprunter ?

Deux possibilits

Le contrleur reprsente le systme global

:ControleurBiblio

Le contrleur ne gre que les oprations systme lies au

cas dutilisation emprunter

:GestionPret

La dcision dutiliser lune ou lautre solution dpend dautres facteurs lis la cohsion et au couplage

Bibliothque

preterLivre()

enregistrerMembre()

..

49

Contrleur Faade

Reprsente tout le systme exemples : ProductController, RetailInformationSystem,

Switch, Router, NetworkInterfaceCard, SwitchFabric, etc.

utiliser quand il y a peu dvnements systme

il nest pas possible de rediriger les vnements systmes un contrleur alternatif

50

Contrleur de cas dutilisation

Un contrleur diffrent pour chaque cas dutilisation

Commun tous les vnements dun cas dutilisation

Permet de connatre et danalyser la squence dvnements systme et ltat de chaque scnario

utiliser quand

les autres choix amnent un fort couplage ou une cohsion faible (contrleur trop charg - bloated)

il y a de nombreux vnements systme qui appartiennent plusieurs processus

Permet de rpartir la gestion entre des classes distinctes et faciles grer

Contrleur artificiel : ce nest pas un objet du domaine

51

Contrleur trop charg (pas bon)

Pas de focus, prend en charge de nombreux domaines de

responsabilit

un seul contrleur reoit tous les vnements systme

le contrleur effectue la majorit des tches ncessaires pour rpondre aux vnements systme

un contrleur doit dlguer dautres objets les tches effectuer

il a beaucoup dattributs et gre des informations importantes du systme ou du domaine

ces informations doivent tre distribues dans les autres objets

ou doivent tre des duplications dinformations trouves dans dautres objets

Solution

ajouter des contrleurs

concevoir des contrleurs dont la priorit est de dlguer

52

Remarque : couche prsentation

Les objets dinterface graphique (fentres, applets) et la couche de prsentation ne doivent pas prendre en charge les vnements systme cest la responsabilit de la couche domaine ou application

:JFramePret

1:valider()

onPretLivre()

:Abonn

: JFramePret

1:emprunterItem()

onPretLivre()

:GestionPret :Abonn 1.1:valider()

53

Contrleur : discussion

Avantages

Meilleur potentiel de rutilisation permet de raliser des composants dinterface enfichables

porte dentre des objets de la couche domaine

la rend indpendante des types dinterface (Web, client riche, simulateur de test)

Niveau dindirection matrialisant la sparation Modle-vue

Brique de base pour une conception modulaire

Meilleure architecturation des CU

Patterns lis

Indirection, Couches, Faade, Fabrication pure, Commande

54

Polymorphisme (GRASP)

Problme

Comment grer des alternatives dpendantes des types ?

Comment crer des composants logiciels enfichables ?

Solution

Affecter les responsabilits aux types (classes) pour lesquels le comportement varie

Utiliser des oprations polymorphes

Polymorphisme

Donner le mme nom des services dans diffrents objets

Lier le client un supertype commun

55

Polymorphisme (GRASP)

Principe

Tirer avantage de lapproche OO en sous-classant les oprations dans des types drivs de lExpert en information

Lopration ncessite la fois des informations et un comportement particuliers

Mise en uvre

Utiliser des classes abstraites

Pour dfinir les autres comportements communs

Sil ny a pas de contre-indication (hritage multiple)

Utiliser des interfaces

Pour spcifier les oprations polymorphes

Utiliser les deux (CA implmentant des interfaces)

Fournit un point dvolution pour dventuels cas particuliers futurs

56

Polymorphisme : exemple

Bibliothque : qui doit tre responsable de savoir si

un exemplaire est disponible ?

Exemplaire

disponible()

Exemplaire

Electronique

disponible()

Exemplaire

Papier

disponible()

Bibliothque

getDispoExemplaires()

Livre

ISBN()

1 *

57

Polymorphisme : discussion

Autre solution (mauvaise)

Utiliser une logique conditionnelle (test sur le type dun objet) au niveau du client

Ncessite de connatre toutes les variations de type

Augmente le couplage

Avantages du polymorphisme volutivit

Points dextension requis par les nouvelles variantes faciles ajouter (nouvelle sous-classe)

Stabilit du client Introduire de nouvelles implmentations naffecte pas les clients

Patterns lis Protection des variations, Faible couplage

58

Fabrication pure (GRASP)

Problme

Que faire

pour respecter le Faible couplage et la Forte cohsion

quand aucun concept du monde rel (objet du domaine) noffre de solution satisfaisante ?

Solution

Affecter un ensemble fortement cohsif une classe artificielle ou de commodit, qui ne reprsente pas un concept du

domaine

entit fabrique de toutes pices

59

Fabrication pure (GRASP)

Exemple typique : quand utiliser lExpert en information

lui attribuerait trop de responsabilits (contrarie Forte cohsion)

le lierait beaucoup dautres objets (contrarie Faible couplage)

Mise en uvre

Dterminer les fonctionnalits annexes de lExpert en information

Les regrouper dans des objets

aux responsabilits limites (fortement cohsifs)

aussi gnriques que possible (rutilisables)

Nommer ces objets

pour permettre didentifier leurs responsabilits fonctionnelles

en utilisant si possible la terminologie du domaine

60

Fabrication pure : exemple

Problme les instances de Prt doivent tre enregistres dans une BD

Solution initiale (daprs Expert) Prt a cette responsabilit

cela ncessite un grand nombre doprations de BD Prt devient donc non cohsif

de lier Prt une BD le couplage augmente pour Prt

Prt

livresPrts:Livre

idAbonn

Serveur:SGBD

editerBulletin()

insertionBD(Object)

majBD(Object)

61

Fabrication pure : exemple (suite)

Constat lenregistrement dobjets dans une BD est

une tche gnrique utilisable par de nombreux objets

pas de rutilisation, beaucoup de duplication

Solution avec Fabrication pure

crer une classe artificielle GestionArchivage

Avantages

Gains pour Prt

Forte cohsion et Faible couplage

Conception de GestionArchivage propre

relativement cohsif, gnrique et rutilisable

GestionArchivage

Serveur:SGBD

insertion(Object)

maj(Object)

Prt

livresPrts:Livre

idAbonn

editerBulletin()

62

Fabrication pure : discussion

Choix des objets pour la conception

Dcomposition reprsentationnelle (objets du domaine)

Conforme au principe de base de lOO : rduire le dcalage des reprsentations entre le rel et le modle

Dcomposition comportementale (Fabrication pure)

sorte dobjet centr-fonction qui rend des services transverses dans un projet (POA)

Ne pas abuser des Fabrications pures

63

Fabrication pure : discussion

Rgle dor

Concevoir des objets Fabrication pure en pensant leur rutilisabilit

sassurer quils ont des responsabilits limites et cohsives

Avantages Supporte Faible couplage et Forte cohsion Amliore la rutilisabilit

Patterns lis Faible couplage, Forte cohsion, Adaptateur, Observateur,

Visiteur

Paradigme li Programmation Oriente Aspects

64

Indirection (GRASP)

Problme

O affecter une responsabilit pour viter le couplage entre deux entits (ou plus)

de faon diminuer le couplage (objets dans deux couches diffrentes)

de faon favoriser la rutilisabilit (utilisation dune API externe) ?

Solution

Crer un objet qui sert dintermdiaire entre dautres composants ou services

lintermdiaire cre une indirection entre les composants

lintermdiaire vite de les coupler directement

65

Indirection (GRASP)

Utilit

Raliser des adaptateurs, faades, etc. (pattern Protection des variations) qui sinterfacent avec des systmes extrieurs

Exemples : proxys, DAO, ORB

Raliser des inversions de dpendances entre packages

Cf. TD sur les compagnies ariennes

Mise en uvre

Utilisation dobjets du domaine

Cration dobjets

Classes : cf. Fabrication pure

Interfaces : cf. Fabrication pure + Polymorphisme

66

Indirection : exemple Bibliothque : accs un systme de stockage

propritaire

:Prt actor

:SystmeStockage

:AdaptateurStockage :Prt actor

:SystmeStockage

enregistrePrt()

xxx()

enregistrePrt() insertion()

xxx()

- Mthode stable

- Reste dans la couche mtier

Communication rseau

(socket TCP)

67

Indirection : discussion

Remarques

Beaucoup de Fabrications pures sont cres pour des raisons dindirection

Objectif principal de lindirection : faible couplage

Adage (et contre adage)

En informatique, on peut rsoudre la plupart des problmes en ajoutant un niveau dindirection (David Wheeler)

En informatique, on peut rsoudre la plupart des problmes de performance en supprimant un niveau dindirection

Patterns lis

GRASP : Fabrication pure, Faible couplage, Protection des variations

GoF : Adaptateur, Faade, Observateur

68

Protection des variations (GRASP)

Problme

Comment concevoir des objets, sous-systmes, systmes pour que les variations ou linstabilit de certains lments naient pas dimpact indsirable sur dautres lments ?

Solution

Identifier les points de variation ou dinstabilit prvisibles

Affecter les responsabilits pour crer une interface (au sens large) stable autour deux (indirection)

69

Protection des variations (GRASP)

Mise en uvre

Cf. patterns prcdents (Polymorphisme, Fabrication pure, Indirection)

Exemples de mcanismes de PV

Encapsulation des donnes, brokers, machines virtuelles

Exercice

Stockage de Prt dans plusieurs systmes diffrents

Utiliser Indirection + Polymorphisme

70

Protection des variations : discussion

Ne pas se tromper de combat Prendre en compte les points de variation

Ncessaires car dentifis dans le systme existant ou dans les besoins

Grer sagement les points dvolution Points de variation futurs, spculatifs : identifier (ne

figurent pas dans les besoins)

Pas obligatoirement implmenter

Le cot de prvision et de protection des points dvolution peut dpasser celui dune reconception

Ne pas passer trop de temps prparer des protections qui ne serviront jamais

71

Protection des variations : discussion

Diffrents niveaux de sagesse le novice conoit fragile

le meilleur programmeur conoit tout de faon souple et en gnralisant systmatiquement

lexpert sait valuer les combats mener

Avantages Masquage de linformation

Diminution du couplage

Diminution de limpact ou du cot du changement

72

Ne pas parler aux inconnus

Cas particulier de Protection des variations protection contre les variations lies aux volutions de

structure des objets

Problme Si un client utilise un service ou obtient de linformation

dun objet indirect (inconnu) via un objet direct (familier du client), comment le faire sans couplage ?

Solution viter de connatre la structure dautres objets indirectement

Affecter la responsabilit de collaborer avec un objet indirect un objet que le client connat directement pour que le client nait pas besoin de connatre ce dernier.

73

Ne pas parler aux inconnus (suite)

Cas gnral viter a.getB().getC().getD().methodeDeD(); Si lune des mthodes de la chane disparat, A devient

inutilisable

Prconisation Depuis une mthode, nenvoyer des messages quaux objets

suivants

lobjet this (self)

un paramtre de la mthode courante

un attribut de this

un lment dune collection qui est un attribut de this

un objet cr lintrieur de la mthode

Implication ajout doprations dans les objets directs pour servir

doprations intermdiaires

74

Ne pas parler aux inconnus : exemple

Comment implmenter disponible() dans GestionPret ?

GestionPret

emprunter(li:Livre)

disponible(li:Livre)

Livre

ISBN

exemplaires():Vector

Exemplaire

disponible():Boolean

nbExDispo():Int

Remarque Pattern connu aussi comme

Loi de Demeter

75

Les patterns GRASP et les autres

Dune certaine manire, tous les autres patterns sont

des applications,

des spcialisations,

des utilisations conjointes

des 9 patterns GRASP, qui sont les plus

gnraux.

76

Plan

Introduction

Patrons GRASP

Design patterns

Patrons architecturaux

Antipatterns

Dfinition

Bonnes pratiques de combinaison dun ensemble de modules, dobjets ou de classes

Rutilisabilit

Maintenabilit

Vocabulaire commun

Porte

Met en scne plusieurs lments (diffrence GRASP)

Rsout un problme localis un contexte restreint (diffrence architecture)

Vocabulaire

Instances, rles, collaboration 77

Catgories de design patterns

Cration

Processus dinstanciation / initialisation des objets

Structure

Organisation dun ensemble de classes travers un module (statique)

Comportement

Organisation des rles pour la collaboration dobjets (dynamique)

Source : http://fr.wikipedia.org/wiki/Patron_de_conception

78

Patterns de cration

Fabrique (Factory Method)

Fabrique abstraite (Abstract Factory)

Monteur (Builder)

Singleton (Singleton)

Prototype (Prototype)

79

80

Notion de Fabrique

Classe responsable de la cration dobjets

lorsque la logique de cration est complexe

lorsquil convient de sparer les responsabilit de cration

Fabrique concrte = objet qui fabrique des instances

Avantages par rapport un constructeur

la classe a un nom

permet de grer facilement plusieurs mthodes de construction avec des signatures similaires

peut retourner plusieurs types dobjets (polymorphisme)

81

Factory method

Factory

un objet qui fabrique des instances conformes une interface ou une classe abstraite

par exemple, une Application veut manipuler des documents, qui rpondent une interface Document

ou une Equipe veut grer des Tactique

82

Factory - Fabrique

(From Grands book.)

La question est : comment

Application peut-elle crer des

instances de Document sans

couplage avec les sous-

classes ?

(T. Horton, CS494)

83

Solution : utiliser une classe DocumentFactory pour

crer diffrents types de documents

(From Grands book.)

(T. Horton, CS494)

84

Factory Method Pattern : structure gnrale

discriminator :

paramtre

indiquant quel type

de sous-classe de

Product crer

(T. Horton, CS494)

(From Grands book.)

Abstract Factory

Objectif

Cration de familles dobjets

Gnralisation du pattern Factory Method

Fonctionnement : fabrication de

fabriques Regroupe plusieurs Factories en une fabrique

abstraite

Le client ne connat que linterface de la fabrique abstraite

Il invoque diffrentes mthodes qui sont dlgues diffrentes fabriques concrtes 85

Abstract Factory

Source :

http://fr.wikipedia.org/wiki/Fabrique_abstraite_(patron_de_conception) 86

Builder

Objectif

Instancier et raliser la configuration initiale dun objet en sabstrayant de linterface de lobjet

Fournir une instance un client

Remarques

Sapplique en gnral des objets complexes

Diffrence avec le pattern [Abstract] Factory

Plutt utilis pour la configuration que pour la gestion du polymorphisme

87

Builder

Source :

http://commons.wikimedia.org/wiki/File:Monteur_classes.png

88

89

Singleton

Objectif Sassurer davoir une instance unique dune

classe Point daccs unique et global pour les autres objets

Exemple : Factory

Fonctionnement Le constructeur de la classe est priv

(seules les mthodes de la classe peuvent y accder)

linstance unique de la classe est stocke dans une variable statique prive

Une mthode publique statique de la classe Cre linstance au premier appel

Retourne cette instance

90

Singleton

Source : http://fr.wikipedia.org/wiki/Singleton_(patron_de_conception)

Prototype

Objectifs

Rutiliser un comportement sans recrer une instance

conomie de ressources

Fonctionnement

Recopie dune instance existante (mthode clone())

Ajout de comportements spcifiques : polymorphisme pas cher

91

Prototype

Source :

http://fr.wikipedia.org/wiki/Prototype_(patron_de_conception)

Remarque

Implmentation choisie pour lhritage en JavaScript (pas de classes) 92

Patterns de structure

Adaptateur (Adapter)

Pont (Bridge)

Objet composite (Composite)

Dcorateur (Decorator)

Faade (Facade)

Poids-mouche ou poids-plume (Flyweight)

Proxy (Proxy)

93

Adaptateur (Adapter, Wrapper)

Objectif

Rsoudre un problme dincompatibilit dinterfaces (API)

Un client attend un objet dans un format donn

Les donnes sont encapsules dans un objet qui possde une autre interface

Fonctionnement

Insrer un niveau dindirection qui ralise la conversion

Patterns lis

Indirection, Proxy 94

Adaptateur (Adapter, Wrapper)

Source :

http://fr.wikipedia.org/wiki/Adaptateur_(patron_de_conception)

95

Faade

Objectif

Cacher une interface / implmentation complexe

rendre une bibliothque plus facile utiliser, comprendre et tester;

rendre une bibliothque plus lisible;

rduire les dpendances entre les clients de la bibliothque

Fonctionnement

Fournir une interface simple regroupant toutes les fonctionnalits utiles aux clients

Patterns lis

Indirection, Adaptateur 96

97

Faade

Client Classes

Subsystem classes

98

Faade : solution

Client Classes

Subsystem classes

Facade

99

Composite

Objectif

Reprsenter une structure arborescente dobjets

Rendre gnrique les mcanismes de positionnement / dplacement dans un arbre

Exemple : DOM Node

Fonctionnement

Une classe abstraite (Composant) qui possde deux sous-classes

Feuille

Composite : contient dantres composants

100

Composite

Source : http://fr.wikipedia.org/wiki/Objet_composite

Remarque

Pourquoi une relation dagrgation et non de composition ?

Proxy

Objectif

Rsoudre un problme daccs un objet

travers un rseau

Qui consomme trop de ressources

Fonctionnement

Crer une classe qui implmente la mme interface

La substituer la classe recherche auprs du client

Patterns lis

Indirection, tat, Dcorateur 101

Proxy

Source : http://en.wikipedia.org/wiki/Proxy_pattern

102

Dcorateur

Objectif

Rsister au changement

Permettre lextension des fonctionnalits dune application sans tout reconcevoir

Principe : les classes doivent tre ouvertes lextension, mais fermes la modification

Fonctionnement

Rajouter des comportements dans une classe qui possde la mme interface que celle dorigine

Appeler la classe dorigine depuis le dcorateur

Pattern li

Proxy 103

Dcorateur

Source : http://en.wikipedia.org/wiki/Decorator_pattern

104

Patterns de comportement

Chane de responsabilit (Chain of responsibility)

Commande (Command)

Interprteur (Interpreter)

Itrateur (Iterator)

Mdiateur (Mediator)

Mmento (Memento)

Observateur (Observer)

tat (State)

Stratgie (Strategy)

Patron de mthode (Template Method)

Visiteur (Visitor)

Fonction de rappel (Callback)

Promesse (Promise) 105

Chane de responsabilit

Objectif

Effectuer plusieurs traitements non lis pour une mme requte

(sparer les responsabilits)

Selon la mme interface

En vitant le couplage entre les objets qui ralisent les traitements

Fonctionnement

Interface commune tous les handlers

Chanage des handlers

Pattern li

Faible couplage 106

Chane de responsabilit

Source :

http://www-sop.inria.fr/axis/cbrtools/usermanual-

eng/Patterns/Chain.html

Variante :

Arbre de responsabilits (dispatcher) 107

Commande

Objectif

Encapsuler la logique mtier dun objet derrire une interface standardise

Fonctionnement

Un Receiver excute les commandes

Des ConcreteCommand appellent chaque mthode mtier du Receiver

Une Command dcrit linterface des ConcreteCommand

Un Invoker stocke les instances de ConcreteCommand pour pouvoir les appeler de

manire standardise 108

Commande

Remarque

Ce pattern introduit un fort couplage entre ses lements

Source : http://en.wikipedia.org/wiki/Command_pattern 109

Interprteur

Objectif

valuer une expression dans un langage particulier

Exemples : expressions mathmatiques, SQL

Fonctionnement

Stocker lexpression dans un contexte (pile)

Dfinir les classes de traitement terminales et non terminales, laide de la mme interface

110

Interprteur

Source : http://en.wikipedia.org/wiki/Interpreter_pattern

111

Mdiateur

Objectif

Dcoupler une structure complexe o un ensemble dobjets interagit avec un autre ensemble

Fonctionnement

Rajouter un niveau dindirection qui gre ces interactions

Patterns lis

Faible couplage, Faade, Adaptateur

112

Mdiateur

Sources : http://sourcemaking.com/design_patterns/mediator

http://www.dofactory.com/Patterns/PatternMediator.aspx 113

Memento

Objectif

Restaurer un tat prcdent dun objet sans violer le principe dencapsulation (pas dattributs publics)

Fonctionnement

Sauvegarder les tats de lobjet dorigine (Originator) dans un autre objet : Memento

Transmettre ce Memento un gardien (CareTaker) pour son stockage

Memento doit tre opaque pour le CareTaker, qui ne doit pas pouvoir le modifier

Ajouter lOriginator des mthodes de sauvegarde et de restauration 114

Memento

Source :

http://sourcemaking.com/design_patterns/memento

115

116

Observateur (Observer)

Contexte Plusieurs objets souscripteurs sont concerns

par les changements dtat dun objet diffuseur

Objectifs Comment faire pour que chacun deux soit inform de ces

changements ?

Comment maintenir un faible couplage entre diffuseur et souscripteurs ?

Fonctionnement (thorique) Dfinir une interface Souscripteur ou Observer

Faire implmenter cette interface chaque souscripteur

Le diffuseur peut enregistrer dynamiquement les souscripteurs intresss par un vnement et le leur signaler

117

Observateur (Observer)

Fonctionnement Un Observateur sattache un Sujet

Le sujet notifie ses observateurs en cas de changement dtat

En pratique Subject : classe abstraite

ConcreteSubject : classe hritant de Subject

Observer : classe (utilise comme classe abstraite)

ConcreteObserver : classe hritant dObserver

Autres noms Diffusion-souscription (publish-subscribe)

Modle de dlgation dvnements

Observateur (Observer)

Source : http://en.wikipedia.org/wiki/Observer_pattern

118

Stratgie

Objectif

Permettre (et orchestrer) le changement dynamique de comportement dun objet

Fonctionnement

Dsencapsuler les comportements de la classe mre de lobjet

Les dporter dans des classes lies, laide dune interface commune

Permettre au client dutiliser une implmentation quelconque de cette interface

Utiliser un contexte qui gre les changements dimplmentation 119

Stratgie

Principes gnraux de conception

Ouvert-ferm : les classes doivent tre

Ouvertes pour lextension

Fermes pour la modification

Privilgier la relation a un la relation est un

Pattern li

tat, Dcorateur

120

Stratgie

Source : http://en.wikipedia.org/wiki/Strategy_pattern

http://sourcemaking.com/design_patterns/strategy

121

tat (State)

Objectif

Changer le comportement apparent dun objet en fonction de son tat

Gnralisation des automates tats (IA)

Fonctionnement

Une interface (State) dfinit le comportement

Des ConcreteState implmentent les comportements

Un Context stocke ltat courant et appelle les comportements correspondants

Les ConcreteState peuvent changer ltat courant dans le contexte

122

tat (State)

Pattern li

Stratgie

Source : http://fr.wikipedia.org/wiki/tat_(patron_de_conception) 123

Fonction de rappel (Callback)

Objectif

Dfinir un comportement sans savoir quel moment il sera dclench

Exemples dutilisation

Synchrone : dclenchement par une bibliothque externe

Asynchrone : modle vnmentiel

Principe

Principe dhollywood Nappelez pas, on vous rappellera.

124

Fonction de rappel (Callback)

Fonctionnement

Langages fonctionnels : passer une fonction en paramtre dune autre fonction

Langages objet : passer un objet (qui encapsule un comportement) en paramtre dune mthode dun autre objet

Patterns lis

Inversion de Contrle (IoC), Observer

125

Fonction de rappel (Callback)

Source : http://en.wikipedia.org/wiki/Callback_(computer_science)

126

Promesse (Promise)

Problme

Certains objets ont des comportements dclenchs par des vnements extrieurs

Objectif

Spcifier le comportement dun objet

Sans savoir comment il sera dclench (asynchrone)

Sans en connatre le rsultat

Fonctionnement

Crer un objet Promise qui encapsule ce comportement et possde trois tats

Pending : la promesse na pas t appele

Fulfilled : la promesse a t appele et sest correctement droule

Rejected : la promesse a t appele et a chou 127

Promesse (Promise)

Discussion

Pattern beaucoup utilis en JS (intgr) ES6

Nest quune simplification de lencapsulation de callbacks

Variantes / extensions

Promise.all()

Promise.race()

Patterns lis

Callback

128

Promesse (Promise)

https://developer.mozilla.org/en-

US/docs/Web/JavaScript/Reference/Global_Objects/Promise

129

130

Plan

Introduction

Patrons GRASP

Design patterns

Patrons architecturaux

Antipatterns

Dfinition

Patrons

Solutions prouves, vocabulaire commun

Objectifs

Organisation dune socit de classes / dobjets

Scope

Niveau de granularit au-dessus des design patterns

Conception de systmes dinformation

Peuvent rutiliser dautres design patterns

131

Dfinition

Exemples de problmes abords

Performance matrielle

Disponibilit

Rutilisation

Utilisation

Conception de systmes dinformation pour lentreprise ( Enterprise Architecture )

Modlisation de lentreprise par les processus : http://en.wikipedia.org/wiki/Enterprise_modelling

Enterprise Architecture (en gnral) : http://en.wikipedia.org/wiki/Enterprise_architecture

Souvent prsents dans les frameworks logiciels 132

Patrons architecturaux

Patrons applicatifs

Permettent dorganiser une application

Exemples

Architecture en couches

Architecture multi-tiers

MV*

IoC

Contexte

Observer ?

133

134

Pattern Couches

package package package

packagepackage

packagepackage

package

package package

Prsentation

(Application)

Domaine

Service

Middleware

Fondation

Architecture multi-tiers

Objectif

Dcoupler les diffrentes fonctionnalits dun programme (sparation des proccupations)

Gestion des donnes, algorithmes mtier, prsentation

Fonctionnement

Concevoir sparment chacune de ces fonctionnalits

Les isoler les unes des autres (autant que possible)

135

Architecture multi-tiers

Exemple (MIF13)

Pattern li

Couches

136

Client Serveur

Donnes

Requtes

HTTP

Rponses

HTTP

HT

TP

Interface Mtier

HT

TP

HTML

137

Modle-Vue-Contrleur

Problme Comment rendre le modle (domaine mtier)

indpendant des vues (interface utilisateur) qui en dpendent ?

Rduire le couplage entre modle et vue

Solution Insrer une couche supplmentaire (contrleur) pour la

gestion des vnements et la synchronisation entre modle et vue

Modle-Vue-Contrleur (suite)

Modle (logique mtier)

Implmente le fonctionnement du systme

Gre les accs aux donnes mtier

Vue (interface)

Prsente les donnes en cohrence avec l'tat du modle

Capture et transmet les actions de l'utilisateur

Contrleur

Gre les changements d'tat du modle

Informe le modle des actions utilisateur

Slectionne la vue approprie

138

139

Modle-Vue-Contrleur (suite)

Source : http://java.sun.com/blueprints/patterns/MVC-detailed.html

Version Java

140

Modle-Vue-Contrleur (suite)

Diffrentes versions

la vue connat le modle ou non

le contrleur connat la vue ou non

le vue connat le contrleur ou non

Mlange avec le pattern Observer

Un ou plusieurs contrleurs ( type 1 / type 2 )

Push-based vs. pull-based

Choix d'une solution

dpend des caractristiques de l'application

dpend des autres responsabilits du contrleur

141

Modle-Vue-Contrleur (suite)

Modle

Vue

Contrleur

Version modle passif la vue se construit partir du modle

le contrleur notifie le modle des changements que lutilisateur spcifie dans la vue

le contrleur informe la vue que le modle a chang et quelle doit se reconstruire

142

Modle-Vue-Contrleur (suite)

Version modle actif quand le modle peut changer indpendamment du contrleur

le modle informe les abonns lobservateur quil sest modifi

ceux-ci prennent linformation en compte (contrleur et vues)

Modle

Vue

Contrleur

interface

Observateur

implements

implements

143

Autres patterns MV* Model-View-Adapter (MVA)

Pas de communication directe entre modle et vue

Un pattern Adapteur (Mdiateur) prend en charge les communications

Le modle est intentionnellement opaque la vue

Il peut y avoir plusieurs adapteurs entre le modle et la vue

Model-View-Presenter (MVP)

La vue est une interface statique (templates)

La vue renvoie (route) les commandes au Presenter

Le Presenter encapsule la logique de prsentation et lappel au modle

Model-View-View Model (MVVM)

Mlange des deux prcdents : le composant View Model

Sert de mdiateur pour convertir les donnes du modle

Encapsule la logique de prsentation

Autre nom : Model-View-Binder (MVB)

Inversion de Contrle (IoC)

Objectif

Ne pas rimplmenter le code gnrique dune application

Permettre ladjonction simple De composants spcifiques mtier

De services annexes disponibles par ailleurs

Fonctionnement

Utiliser un Conteneur capable de

Grer le flot de contrle de lapplication

Instancier des composants

Rsoudre les dpendances entre ces composants

Fournir des services annexes (scurit, accs aux donnes)

144

Inversion de Contrle (IoC)

Exemple (MIF13)

Autre nom

Injection de dpendances 145

Code de

lapplication Framework

Bibliothque

Bibliothque

Bibliothque

Code de

lapplication

Code de

lapplication

Code de

lapplication

Flo

t d

ex

cu

tio

n

Flo

t d

ex

cu

tio

n

Patrons architecturaux

Patrons applicatifs (suite)

Patrons dauthentification

Directe, laide dune plateforme

Single Sign On (CAS)

Patrons dautorisation

Rles, attributs, activit, utilisateur, heure

Patrons de scurit

Checkpoint, standby, dtection/correction derreurs

146

Patrons architecturaux

Patrons de donnes

Architecture des donnes

Transactions, oprations, magasins, entrepts

Modlisation de donnes

Relationnelle, dimensionnelle

Gouvernance des donnes (Master Data Management)

Rplication, services daccs, synchronisation

147

Patrons architecturaux

Types darchitectures et doutils

Plateformes de composants (frameworks)

Architectures orientes services (SOA)

Extract Transform Load

Enterprise Application Infrastructure / Enterprise Service Bus

148

149

Patterns of Enterprise

Application Architecture Origine

Livre de Martin Fowler, Dave Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford, 2002

Contenu

Formalisation de lexprience de dveloppement d Enterprise Applications

Gnralisation didiomes de plusieurs langages

Une quarantaines de patterns souvent assez techniques

Exemples

Service Layer, Foreign Key Mapping, MVC, Front Controller, DTO, Registry, Service Stub

Rfrence

http://martinfowler.com/eaaCatalog/

150

Plan

Introduction

Patrons GRASP

Design patterns

Patrons architecturaux

Antipatterns

151

Anti-patrons Erreurs courantes de conception documentes

Caractriss par Lenteur du logiciel

Cots de ralisation ou de maintenance levs

Comportements anormaux

Prsence de bogues

Exemples Action distance

Emploi massif de variables globales, fort couplage

Coule de lave Partie de code encore immature mise en production, forant la

lave se solidifier en empchant sa modification

Rfrence http://en.wikipedia.org/wiki/Anti-pattern

152

Conclusion

On a vu assez prcisment les patterns

les plus gnraux (GRASP)

On a survol les autres

un bon programmeur doit les tudier et en connatre une cinquantaine

On a peine abord les anti-patterns

Les connatre est le meilleur moyen de dtecter que votre projet est en train de

153

IDE orients Design patterns

Fournir une aide linstanciation ou au reprage de patterns

ncessite une reprsentation graphique (au minimum collaboration UML) et le codage de certaines contraintes

Instanciation

choix dun pattern, cration automatique des classes correspondantes

Reprage

assister lutilisateur pour reprer

des patterns utiliss (pour les documenter)

des presque patterns (pour les faire tendre vers des patterns)

Exemples doutils

Eclipse + plugin UML

Describe + Jbuilder

IntelliJ

154

Remerciements

Yannick Pri

Latitia Matignon

Olivier Aubert

Rfrences

Ouvrage du Gang of Four Eric Gamma, Richard Helm, Ralph Johnson, John Vlissides

(1994), Design patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 395 p. (trad. franaise : Design patterns. Catalogue des modles de conception rutilisables, Vuibert 1999)

Plus orient architecture Martin Fowler (2002) Patterns of Enterprise Application

Architecture, Addison Wesley

En Franais

Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates, Design Patterns Tte la premire, OReilly Eds., 640 p., 2005.

155

Rfrences

Sur le Web

http://fr.wikipedia.org/wiki/Patron_de_conception

http://en.wikipedia.org/wiki/Category:Software_design_patterns

http://en.wikipedia.org/wiki/Architectural_pattern

http://stackoverflow.com/questions/4243187/difference-between-design-pattern-and-architecture

http://martinfowler.com/eaaCatalog/

http://www.hillside.net/patterns

http://java.sun.com/blueprints/corej2eepatterns/

https://www.promisejs.org/

156