Download - CM Patterns
-
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