1. Réutilisation dans les SI : patrons de conception Yannick Prié Département Informatique – Faculté de Sciences et Technologies Université Claude Bernard Lyon 1 2011-2012

3. nécessité pratique depuis qu’il y a des outils, et que ceux-ci évoluent

4. Exemples = comment concevoir

5. une chaise ?

6. un tournevis ?

7. un bateau ?

8. un parc ?2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 2

10. codage, réseaux, normes, principes, etc.

11. Réutilisation de code

12. composants / librairies / services

13. à utiliser / acheter / fabriquer

14. frameworks

15. à utiliser en les spécialisant

16. Réutilisation de modèles de données

17. schémas

18. Réutilisation de principes de conception

19. IHM

20. Tendance générale informatique

21. dès que quelque chose se révèle pertinent

22. abstraction / réutilisation / normalisation2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 3

23. Plan Introduction sur les patterns Patrons GRASP Design patterns 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 4

24. Généralités sur les patterns Pattern solution classique à un problème de conception classique dans un contexte donné Pattern de conception structure et comportement d’une société de classes description nommée d’un problème et d’une solution avec conseils d’application 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 5

27. solution : description abstraite

29. Refactoring / réingénierie Définition réécriture de parties de code pour obtenir des services équivalents avec une conception meilleure Quand ? Il existe des indicateurs de problèmes (code smells) Une fois identifiés, on peut corriger le code Exemples (www.refactoring.com) You have a code fragment that can be grouped together. Turn the fragment into a method whose name explains the purpose of the method. You have a class that is in a package that contains other classes that it is not related to in function. Move the class to a more relevant package. Or create a new package if required for future use. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 7

30. Plan Introduction sur les patterns Patrons GRASP Design patterns 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 8

32. la façonhumaine, conceptuelle de penser le domaine

33. « un échiquier a des cases »

34. les objets logiciels correspondants

35. un objet Echiquier contient des objets Case

36. vs. un objet Echiquier contient 4 objets 16Cases

37. vs. un objet TYR43 contient des EE25

38. Ce décalage doit être réduit au maximum

39. Les concepts du domaine évoluent peu, les objets peuvent suivre l’évolution

40. adaptation, réutilisation2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 9

42. communauté d’objets responsables qui collaborent (cf. humains) dans un projet (rôles)

43. Principe

44. penser l’organisation des composants (logiciels ou autres) en termes de responsabilités par rapport à des rôles, au sein de collaborations

45. Responsabilité

46. abstraction de comportement (contrat, obligation) par rapport à un rôle

47. une responsabilité n’est pas une méthode

48. les méthodes s’acquittent des responsabilités2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 10

50. connaître les données privées encapsulées

51. connaître les objets connexes

52. connaître les attributs à calculer ou dériver

53. Faire

54. faire quelque chose soi-même (ex. créer un autre objet, effectuer un calcul)

55. déclencher une action d’un autre objet

56. contrôler et coordonner les activités d’autres objets2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 11

57. Exemple (agence de voyage) Savoir Réservation est responsable de la connaissance de son numéro et du voyageur associé Vol est responsable de savoir s’il reste des places Faire Client est responsable de la construction des réservations 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 12

58. Patterns GRASP General ResponsabilityAssignment Software Patterns Ensemble de patterns généraux d’affectation de responsabilités pour aider à la conception orientée-objet raisonner objet de façon méthodique, rationnelle, explicable Utile pour l’analyse et la conception réalisation d’interactions avec des objets Référence : Larman 2004 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 13

59. 9 patterns GRASP Expert en information Créateur Faible couplage Forte cohésion Contrôleur Polymorphisme Fabrication pure Indirection Protection des variations 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 4 grands principes de conception et d’évaluation : Expert, Créateur, Faible couplage, Forte cohésion 2 outils : Fabrication pure et Indirection 3 applications des précédents : Contrôleur, Polymorphisme, Protection des variations 14

60. Expert (GRASP) Problème Quel est le principe général d’affectation des responsabilités aux objets ? Solution Affecter la responsabilité à l’expert en information la classe qui possède les informations nécessaires pour s’acquitter de la responsabilité 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 15

61. Expert : exemple Bibliothèque : qui doit avoir la responsabilité de connaître l’identifiant de l’abonné ? De connaître le titre d’un livre ? De connaître la disponibilité d’un exemplaire ? qui doit avoir la responsabilité de connaître le nombre d’exemplaires disponibles ? 0..* emprunte 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 16

62. Expert : exemple Commencer avec la question De quelle information a-t-on besoin pour déterminer le nombre d’exemplaires disponibles ? Disponibilité de toutes les instances d’exemplaires Puis Qui en est responsable ? Livre est l’Expert pour cette information 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 17

63. Expert : exemple 0..* emprunte 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 18

65. Quand l’accomplissement d’une responsabilité nécessite de l’information répartie entre différents objets

66. La tâche globale est décomposée en sous-tâches locales

67. La responsabilité est assurée par la collaboration entre experts « locaux » avec

68. données propres

69. responsabilités correspondantes2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 19

70. Expert : exemple (suite) contient 0..* concerne 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 20

71. Expert : exemple (suite) :Bibliothèque 1: n=nbLivresEnRayon() 1.1: n1=nbExemplaires() :Exemplaire 1.2: n2=nbExemplaires() 1.1.1:d=getDispo() Livres[0]:Livre :Exemplaire 1.1.2: d=getDispo() Livres[1]:Livre :Exemplaire 1.2.1 d=getDispo() 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 21

73. Encapsulation

74. les objets utilisent leurs propres informations pour mener à bien leurs tâches

75. Collaboration

76. le comportement est distribué entre les classes ayant l’information nécessaire

77. Favorise

78. Couplage faible (GRASP)

79. Systèmes robustes et maintenables

80. Forte cohésion (GRASP)

81. classes légères, faciles à comprendre, à maintenir, à réutiliser2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 22

83. Autres noms (AKA - AlsoKnown As)

84. « Mettre les responsabilités avec les données »

85. « Qui sait, fait »

86. « Faire soi-même »

87. Patterns liés (voir plus loin)

88. Faible couplage

89. Forte cohésion2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 23

91. Qui doit avoir la responsabilité de créer une nouvelle instance d’une classe donnée ?

92. Solution

93. Affecter à la classe B la responsabilité de créer une instance de la classe A si une - ou plusieurs - de ces conditions est vraie :

94. B contient, agrège ou est composé d’objets A

95. B enregistre des objets A

96. B utilise étroitement des objets A

97. B a les données d’initialisation qui seront transmises aux objets A lors de leur création

98. ie. B est un Expert en ce qui concerne la création de A2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 24

99. Créateur : exemple Bibliothèque : qui doit être responsable de la création de Pret? contient 0..* concerne BasePret contient des Pret : elle doit les créer. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 25

101. une tâche très commune en OO

102. Finalité : trouver un créateur pour qui il est nécessaire d’être connecté aux objets créés

103. favorise le Faible couplage

104. moins de dépendances de maintenance, plus d’opportunités de réutilisation

105. Pattern liés

106. Faible couplage

107. Composite

108. Fabricant2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 26

109. Faible couplage (GRASP) Problème Comment minimiser les dépendances ? Comment réduire l’impact des changements ? Comment améliorer la réutilisabilité ? Solution Affecter les responsabilités des classes de sorte que le couplage reste faible Appliquer ce principe lors de l’évaluation des solutions possibles 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 27

111. Mesure du degré auquel un élément est lié à un autre, en a connaissance ou en dépend

112. Exemples classiques de couplage de TypeX vers TypeYdans un langage OO

113. TypeX a un attribut qui réfère à TypeY

114. TypeX a une méthode qui référence TypeY

115. TypeX est une sous-classe directe ou indirecte de TypeY

116. TypeY est une interface et TypeXl’implémente

117. Les dépendances sont directement liées au couplage2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 28

119. Un changement dans une classe force à changer toutes ou la plupart des classes liées

120. Les classes prises isolément sont difficiles à comprendre

121. Réutilisation difficile : l’emploi d’une classe nécessite celui des classes dont elle dépend

122. Bénéfices du couplage faible

123. Exactement l’inverse

124. Une classe faiblement couplée a une faible dépendance aux autres classes2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 29

126. les classes génériques et réutilisables par nature doivent avoir un faible couplage

127. Mise en œuvre

128. déterminer plusieurs possibilités pour l’affectation des responsabilités

129. comparer leurs degrés de couplage en termes de

130. nombre de relations entre les classes

131. nombre de paramètres circulant dans l’appel des méthodes

132. fréquence des messages

133. …2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 30

134. Faible couplage : exemple makePaiement() 1: create() :RegistreVente p : Paiement 2: addPaiement(p) :Vente makePaiement() 1: makePaiement() :RegistreVente :Vente 1.1. create() :Paiement Que choisir ? 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 31

137. Ne doit pas être considéré indépendamment d’autres patterns comme Expert et Forte cohésion

138. en général, Expert soutient Faible couplage

139. Pas de mesure absolue de quand un couplage est trop fort

140. Un fort couplage n’est pas dramatique avec des éléments très stables

141. java.util par exemple2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 33

143. des objets incohérents, complexes, qui font tout le travail

144. des objets isolés, non couplés, qui servent à stocker les données

146. un couplage modéré est nécessaire et normal pour créer des systèmes OO 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 34

148. Comment s’assurer que les objets restent

149. compréhensibles ?

151. Attribuer les responsabilités de telle sorte que la cohésion reste forte

152. Appliquer ce principe pour évaluer les solutions possibles2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 35

153. Définition cohésion Cohésion (ou cohésion fonctionnelle) mesure informelle de l’étroitesse des liens et de la spécialisation des responsabilités d’un élément (d’une classe) relations fonctionnelles entre les différentes opérations effectuées par un élément volume de travail réalisé par un élément 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 36

155. Elle effectuent

156. trop de tâches

157. des tâches sans lien entre elles

158. Elles sont

159. difficiles à comprendre

160. difficiles à réutiliser

161. difficiles à maintenir

162. fragiles, constamment affectées par le changement

163. Bénéfices de la forte cohésion : …2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 37

164. Forte cohésion (suite) Une classe qui est fortement cohésive a des responsabilités étroitement liées les unes aux autres petit nombre de méthodes fonctionnalités entre méthodes liées n’effectue pas un travail gigantesque Un test Peut-on décrire la classe avec une seule phrase ? 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 38

168. Forte cohésion : discussion Citations [Booch] : Il existe une cohésion fonctionnelle quand les éléments d’un composant (eg. les classes) « travaillent tous ensemble pour fournir un comportement bien délimité » [Booch] : « la modularité est la propriété d’un système qui a été décomposé en un ensemble de modules cohésifs et peu couplés » 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 41

170. Quel est le premier objet au delà de l’IHM qui reçoit et coordonne (contrôle) une opération système (= événement majeur entrant dans le système) ?

171. Solution

172. Affecter cette responsabilité à une classe qui représente

173. Soit le système global, un sous-système majeur ou un équipement sur lequel le logiciel s’exécute contrôleur Façade ou variantes

174. Soit un scénario de cas d’utilisation dans lequel l’événement système se produitcontrôleur de cas d’utilisation ou contrôleur de session2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 42

175. Deux types de contrôleurs Contrôleur Façade ContrôleurS de cas d’utilisation IHM IHM Contrôleur Facade ContrôleurCU1 ContrôleurCU2 ContrôleurCU3 ... Domaine Domaine 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 43

176. Contrôleur Façade Représente tout le système exemples : ProductController, RetailInformationSystem, Switch, Router, NetworkInterfaceCard, SwitchFabric, etc. À utiliser quand il y a peu d’événements système un seul contrôleur suffit il n’est pas possible de rediriger les événements systèmes à un contrôleur alternatif 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 44

177. Contrôleur de cas d’utilisation Un contrôleur différent pour chaque cas d’utilisation gère tous les événements d’un même cas d’utilisation permet de connaître et d’analyser la séquence d’événements système et l’état de chaque scénario À utiliser quand les autres choix amènent à un fort couplage ou à une cohésion faible (contrôleur trop chargé - bloated) il y a de nombreux événements système qui appartiennent à plusieurs processus Permet de répartir la gestion entre des classes distinctes et faciles à gérer Contrôleur de CU = classe artificielle ce n’est pas un objet du domaine au contraire d’un contrôleur Façade qui correspondra par exemple à l’application complète (eg. Bibliotheque) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 45

179. un contrôleur est un objet qui ne fait rien

180. reçoit les événements système

181. délègue aux objets dont la responsabilité est de les traiter

182. il se limite aux tâches de contrôle et de coordination

183. vérification de la séquence des événements système

184. appel des méthodes ad hoc des autres objets

185. il peut gérer des fonctionnalités transversales

186. eg authentification

187. Règle d’or

188. Les opérations système des CU sont les messages initiaux qui parviennent au contrôleur dans les diagrammes d’interaction de la couche domaine2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 46

189. Contrôleur Mise en œuvre Au cours de la détermination du comportement du système (besoins, CU, DSS), les opérations système sont déterminées et attribuées à une classe générale Système À l’analyse/conception, des classes contrôleur sont mises en place pour prendre en charge ces opérations 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 47

190. Contrôleur : exemple Pour la gestion d’une bibliothèque, qui doit être contrôleur pour l’opération système emprunter ? Deux possibilités Le contrôleur représente lesystème global :Bibliothèque Le contrôleur ne gère que lesopérations système liées aucas d’utilisation emprunter :GestionPret La décision d’utiliser l’une ou l’autre solution dépend d’autres facteurs liés à la cohésion et au couplage 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 48

192. un seul contrôleur reçoit tous les événements système

193. le contrôleur effectue la majorité des tâches nécessaires pour répondre aux événements système

194. un contrôleur doit déléguer à d’autres objets les tâches à effectuer

195. il a beaucoup d’attributs et gère des informations importantes du système ou du domaine

196. ces informations doivent être distribuées dans les autres objets

197. ou doivent être des duplications d’informations trouvées dans d’autres objets

198. Solution

199. ajouter des contrôleurs

200. concevoir des contrôleurs dont la priorité est de déléguer2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 49

201. Remarque : couche présentation Les objets d’interface graphique (fenêtres, applets) et la couche de présentation ne doivent pas prendre en charge les événements système c’est la responsabilité de la couche domaine ou application onPretLivre() onPretLivre() :JFramePret : JFramePret 1:emprunterItem() 1:valider() 1.1:valider() :GestionPret :Abonné :Abonné 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 50

203. Meilleur potentiel de réutilisation

204. permet de réaliser des composants d’interface enfichables

205. « porte d’entrée » vers les objets de la couche domaine

206. la rend indépendante des types d’interface (Web, client riche, simulateur de test…)

207. Niveau d’indirection matérialisant la séparation Modèle-Vue

208. Brique de base pour une conception modulaire

209. Meilleure « architecturation » des CU

210. Patterns liés

211. Indirection, Couches, Façade, Fabrication pure, Commande2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 51

213. Comment gérer des alternatives dépendantes des types ?

214. Comment créer des composants logiciels « enfichables » ?

215. Solution

216. Affecter les responsabilités aux types (classes) pour lesquels le comportement varie

217. Utiliser des opérations polymorphes

218. Polymorphisme

219. Donner le même nom à des services dans différents objets

220. Lier le « client » à un supertype commun2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 52

222. Tirer avantage de l’approche OO en sous-classant les opérations dans des types dérivés de l’Expert en information

223. L’opération nécessite à la fois des informations et un comportement particuliers

224. Mise en œuvre

225. Utiliser des classes abstraites

226. Pour définir les autres comportements communs

227. S’il n’y a pas de contre-indication (héritage multiple)

228. Utiliser des interfaces

229. Pour spécifier les opérations polymorphes

230. Utiliser les deux (CA implémentant des interfaces)

231. Fournit un point d’évolution pour d’éventuels cas particuliers futurs2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 53

234. Nouvelle situation : un Exemplaire est une sort d’Artefact1 * 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 55

236. Utiliser une logique conditionnelle (test sur le type d’un objet) au niveau du client

237. Nécessite de connaître toutes les variations de type

238. Augmente le couplage

239. Avantages du polymorphisme

240. Évolutivité

241. Points d’extension requis par les nouvelles variantes faciles à ajouter (nouvelle sous-classe)

242. Couplage faible avec le client

243. Introduire de nouvelles implémentations n’affecte pas les clients

244. Patterns liés

245. Protection des variations, Faible couplage2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 56

247. Que faire

248. pour respecter le Faible couplage et la Forte cohésion

249. quand aucun concept du monde réel (objets du domaine) n’offre de solution satisfaisante ?

250. ie le modèle du domaine ne fournit pas de classe adéquate

251. Solution

252. affecter un ensemble fortement cohésif à une classe artificielle ou de commodité, qui ne représente pas un concept du domaine

253. entité fabriquée de toutes pièces2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 57

255. Utiliser l’Expert en information

256. lui attribuerait trop de responsabilités (contrarie Forte cohésion)

257. le lierait à beaucoup d’autres objets (contrarie Faible couplage)

258. Mise en œuvre

259. Déterminer les fonctionnalités « annexes » de l’Expert en information

260. Les regrouper dans des objets

261. aux responsabilités limitées (fortement cohésifs)

262. aussi génériques que possible (réutilisables)

263. Nommer ces objets

264. pour permettre d’identifier leurs responsabilités fonctionnelles

265. en utilisant éventuellement la terminologie du domaine

266. en général difficile2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 58

268. les instances de Prêt doivent être enregistrées dans une BD

269. Solution initiale (d’après Expert)

270. Prêt a cette responsabilité

271. cela nécessite

272. un grand nombre d’opérations de BD Prêt devient donc non cohésif

273. de lier Prêt à une BDle couplage augmente pour Prêt2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 59

275. l’enregistrement d’objets dans une BD est une tâche générique utilisable par de nombreux objets

276. pas de réutilisation, beaucoup de duplication

277. Solution avec Fabrication pure

278. créer une classe artificielle GestionArchivage

279. Avantages

280. Gains pour Prêt

281. Forte cohésion et Faible couplage

282. Conception de GestionArchivage« propre »

283. relativement cohésif, générique et réutilisable2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 60

285. décomposition représentationnelle (à partir des concepts du domaine)

286. conforme au principes de base de l’OO

287. encapsulation données / traitements

288. réduction du décalage des représentations entre le réel et le modèle

289. décomposition comportementale (Fabrication pure)

290. sortes d’objets « centré-fonction » qui rendent des services transverses dans un projet (POA)

291. Ne pas abuser des Fabrications pures2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 61

293. Concevoir des objets Fabrication pure en pensant à leur réutilisabilité

294. s’assurer qu’ils ont des responsabilités limitées et cohésives

295. Avantages

296. Supporte Faible couplage et Forte cohésion

297. Améliore la réutilisabilité

298. Patterns liés

299. Faible couplage, Forte cohésion, Adaptateur, Observateur, Visiteur

300. Paradigme lié

301. Programmation Orientée Aspects2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 62

303. Où affecter une responsabilité pour éviter le couplage entre deux entités (ou plus)

304. de façon à diminuer le couplage (objets dans deux couches différentes) ?

305. de façon à favoriser la réutilisabilité (utilisation d’une API externe) ?

306. Solution

307. Créer un objet qui sert d’intermédiaire entre d’autres composants ou services

308. l’intermédiaire crée une indirection entre les composants

309. l’intermédiaire évite de les coupler directement2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 63

311. Réaliser des adaptateurs, façades, etc. (pattern Protection des variations) qui s’interfacent avec des systèmes extérieurs

312. Exemples : proxys, DAO (Data Access Object), ORB (Object Request Broker)

313. Réaliser des inversions de dépendances entre packages

314. Cf. TD sur les compagnies aériennes

315. Mise en œuvre

316. Utilisation d’objets du domaine

317. Création d’objets

318. Classes : cf. Fabrication pure

319. Interfaces : cf. Fabrication pure + Polymorphisme2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 64

322. Beaucoup de Fabrications pures sont créées pour des raisons d’indirection

323. Objectif principal de l’indirection : faible couplage

324. Adage (et contre adage)

325. « En informatique, on peut résoudre la plupart des problèmes en ajoutant un niveau d’indirection » (David Wheeler)

326. « En informatique, on peut résoudre la plupart des problèmes de performance en supprimant un niveau d’indirection »

327. Patterns liés

328. GRASP : Fabrication pure, Faible couplage, Protection des variations

329. GoF : Adaptateur, Façade, Observateur…2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 66

331. Comment concevoir des objets, sous-systèmes, systèmes pour que les variations ou l’instabilité de certains éléments n’aient pas d’impact indésirable sur d’autres éléments ?

332. Solution

333. Identifier les points de variation ou d’instabilité prévisibles

334. Affecter les responsabilités pour créer une interface (au sens large) stable autour d’eux (indirection)2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 67

336. Cf. patterns précédents (Polymorphisme, Fabrication pure, Indirection)

337. Exemples de mécanismes de PV

338. Encapsulation des données, brokers, machines virtuelles…

339. Exercice

340. Point de variation = stockage de Prêt dans plusieurs systèmes différents

341. Utiliser Indirection + Polymorphisme2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 68

343. Prendre en compte obligatoirement les points de variation

344. Nécessaires car identifiés dans le système existant ou dans les besoins

345. Gérer sagement les points d’évolution

346. Points de variation futurs, « spéculatifs » : à identifier (ne figurent pas dans les besoins)

347. Pas obligatoirement à implémenter

348. Le coût de prévision et de protection des points d’évolution peut dépasser celui d’une reconception

349. Ne pas passer trop de temps à préparer des protections qui ne serviront jamais2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 69

350. Protection des variations : discussion Différents niveaux de sagesse le novice conçoit fragile le meilleur programmeur conçoit tout de façon souple et en généralisant systématiquement l’expert sait évaluer les combats à mener Avantages Masquage de l’information Diminution du couplage Diminution de l’impact ou du coût du changement 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 70

352. protection contre les variations liées aux évolutions de structure des classes du système

353. Problème

354. Comment éviter de connaître la structure d’autres objets indirectement ?

355. Si un client utilise un service ou obtient de l’information d’un objet indirect (inconnu), comment le faire sans couplage ?

356. Solution

357. Éviter de connaître la structure d’autres objets indirectement

358. se limiter aux objets connus directement

359. Affecter la responsabilité de collaborer avec un objet indirectà un objet que le client connaît directementpour que le client n’ait pas besoin de connaître ce dernier2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 71

361. A est dépendant de B, C et D

362. si l’une des méthodes de la chaîne disparaît, A devient inutilisable

363. tout changement de methodeDeD() peut avoir une conséquence sur A

364. Préconisation (« Loi de Demeter »)

365. Depuis une méthode, n’envoyer des messages qu’aux objets suivants

366. l’objet this(self)

367. un paramètre de la méthode courante

368. un attribut de this

369. un élément d’une collection qui est un attribut de this

370. un objet créé à l’intérieur de la méthode

371. Implication

372. ajout d’opérations dans les objets directs pour servir d’opérations intermédiaires2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 72

373. Ne pas parler aux inconnus : exemple Comment implémenter disponible() dans GestionPret ? 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 nbExDispo():Int 73

374. Principe DRY / DIE DRY : Don't Repeat Yourself DIE : Duplication is Evil Principe général de conception / programmation "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system" S’applique à tout le système : code, configuration, modèles, documentation, etc. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 74

375. Les patterns GRASP et les autres D’une certaine manière, tous les autres patterns sont des applications, des spécialisations, des utilisations conjointes des 9 patterns GRASP, qui sont les plus généraux. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 75

376. Plan Introduction sur les patterns Patrons GRASP Design patterns 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 76

377. Généralités Origine dans l’architecture ouvrages de Christopher Alexander (77) http://www.math.utsa.edu/sphere/salingar/patterninteractive-french.html Propriétés pragmatisme solutions existantes et éprouvées récurrence bonnes manières de faire éprouvées générativité comment et quand appliquer, indépendance au langage de programmation émergence la solution globale émerge de l’application d’un ensemble de patrons Exemples : entrée, couloir 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 77

379. architecture

380. conception de systèmes

381. conception

382. interaction de composants

383. comportement

384. structure

385. création

386. idiomes de programmation

387. techniques, styles spécifiques à un langage

388. Patrons d’analyse

389. Patrons d’organisation

390. … (O. Aubert) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 78

392. Eric Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994), Design patterns, Elements of ReusableObject-Oriented Software, Addison-Wesley, 395 p. (trad. française : Design patterns. Catalogue des modèles de conception réutilisables, Vuibert 1999)

393. Plus orienté architecture

394. Martin Fowler (2002) Patterns of Enterprise Application Architecture, Addison Wesley

395. Deux ouvrages récents en français

396. 23 patterns de conception / JAVA

397. Sites

398. http://www.hillside.net/patterns

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

400. …2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 79

402. Évocateur, référence concise

403. Problème

404. Objectifs que le patron cherche à atteindre

405. Contexte initial

406. Comment le problème survient

407. Quand la solution fonctionne

408. Forces/contraintes

409. Forces et contraintes interagissant au sein du contexte

410. Détermination des compromis

411. Solution

412. Comment mettre en œuvre la solution ?

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

414. Variantes de solutions(O. Aubert) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 80

416. Exemples d’applications

417. Contexte résultant

418. Description du contexte résultant de l’application du patron au contexte initial

419. Conséquences positives et négatives

420. Justification

421. Raisons fondamentales conduisant à l’utilisation du patron

422. Réflexions sur la qualité du patron

423. Patrons associés

424. Similaires ou possédant des contextes initial ou résultant proches

425. Utilisations connues

426. Exemples d’applications réels(O. Aubert) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 81

427. Les patrons ne sont pas Limités au domaine informatique Des idées nouvelles Des solutions qui n’ont fonctionné qu’une seule fois Des principes abstraits ou des heuristiques Une panacée (O. Aubert) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 82

429. Spécifiques au domaine d’utilisation

430. Rien d’exceptionnel pour les experts d’un domaine

431. Une forme littéraire pour documenter des pratiques

432. Un vocabulaire partagé pour discuter de problèmes

433. Un moyen efficace de réutiliser et partager de l’expérience2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 83

435. Caractérisés par

436. lenteur du logiciel

437. coûts de réalisation ou de maintenance élevés

438. comportements anormaux

439. présence de bogues.

440. Exemples

441. Action à distance

442. Emploi massif de variables globales, fort couplage

443. Coulée de lave

444. Partie de code encore immature mise en production, forçant la lave à se solidifier en empêchant sa modification

445. …(wikipedia) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 84

446. Présentation(Application)DomaineServiceMiddlewareFondation Pattern Couches Couche classiques 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 85

448. organiser le systèmes en différentes couches

449. Principes

450. chaque couche communique seulement avec une couche située en dessous

451. chaque couche contient un ou plusieurs packages aux interfaces bien définies

452. une couche du dessus voit une couche du dessous comme un ensemble de services

453. deux couches peuvent fournir des mêmes fonctionnalités, mais à des niveaux d’abstraction différents (eg. couches réseaux)

454. l’interface graphique doit obligatoirement se trouver dans une couche spécifique

455. la couche sous la couche IHM fournit les fonctions déterminées par les cas d’utilisation (cf. Contrôleur)

456. les couches du bas fournissent des services généraux (e.g. communication réseau, accès base de données, etc.)

457. les couches peuvent tourner sur des machines différentes , auquel cas on parlera de tiers (architectures multi-tiers)2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 86

459. Les couches peuvent être conçues indépendamment les unes des autres

460. Réduction du couplage

461. Pas de dépendances des couches basses aux couches hautes

462. Plus de flexibilité

463. Possibilité d’ajouter des fonctionnalités au-dessus de services bas niveau, ou de remplacer des couches hautes

464. Conception portable

465. isoler les modules interdépendants dans une couche

466. Conception plus facile à tester

467. Les couches peuvent être testées indépendamment les unes des autres

468. Permet de concevoir défensivement

469. Les API des couches sont le lien naturel où faire des tests rigoureux 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 87

470. Adapter - Adaptateur (GoF) Problème comment un client peut-il utiliser une classe existante suivant une interface qu’il définit lui-même ? Solution mettre en place un adapter qui fournira l’interface désirée en utilisant les services de la classe existante 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 88

471. Adaptateur de classe 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 89

472. Adaptateur d’objet Si on n’a pas d’interface 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 90

473. Façade (Gof) Problème comment offrir une manière simple d’utiliser un ensemble de services rendus par plusieurs classes d’un package ? comment donner une interface bien conçue à un package mal conçu ? Solution utiliser une classe Façade qui fournit une interface simplifiant l’emploi d’un sous-système (pour les tâches les plus communes) offrant un accès bien défini et correspondant aux besoins des clients 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 91

474. Client Classes Subsystem classes Façade (GoF) : solution Facade 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 92

475. Composite (GoF) Problème Comment modéliser des compositions d’éléments en gérant des comportements de façon unifiée Solution Utiliser une structure composite permettant aux clients de traiter de façon uniforme des objets individuels et des composition d’objets 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 93

476. Composite (GoF) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <<abstract>> 94

477. Composite (exercice) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Comment implémenter les divers compteNoeuds() ? 95 <<abstract>>

478. Singleton (GoF) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Problème Comment garantir qu’une classe a une instance unique et comment fournir un point d’accès unique et global à cette instance ? Solution Créer une classe singleton 96

479. Singleton (GoF) -ClasseSingleton instanceUnique -singletonData UML Utiliser une méthode statique de la classe qui retourne l’instance Constructeur privé ou protégé Utilisation par des threads : attention ! 1 ClasseSingleton -Singleton() +getInstance() : ClasseSingleton +getSingletonData() 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 public staticgetInstance() { if (instanceUnique == NULL) { instanceUnique = new ClasseSingleton() ; // … return instanceUnique ; } 97

480. Observer - Observateur (GoF) Problème Comment des clients qui dépendent d’un objet peuvent-il savoir que l’état de cet objet a changé ? Comment avoir un couplage faible entre cet objet et les clients ? Solution Introduire une dépendance (1,n) entre des objets de manière que, lorsqu’un objet (diffuseur), change d’état tous les objets dépendants (souscripteurs) en soient notifiés. Donner la responsabilité au souscripteur de demander la notification au diffuseur de prévenir les clients concernés 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 98

482. Faire implémenter cette interface à chaque souscripteur

483. Le diffuseur peut enregistrer dynamiquement les souscripteurs intéressés par un événement et le leur signaler2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Subject : souvent classe abstraite Observer : interface 99

484. Observateur (suite) Souvent utilisé pour les IHM (voir pattern MVC) Autres noms Diffusion-souscription Modèle de délégation d’événements Observateur est derrière le modèle événementiel en Java java.util.Observer, java.util.Observable Rq : si impossibilité de spécialiser Observable attacher une sous-classe d’Observable à l’objet diffuseur 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 100

485. Mediator (GoF) Problème Que faire lorsque la trop grande complexité d’une distribution de responsabilités entre objets nécessite une autorité centrale ? Solution Définir un objet médiateur qui encapsule la façon dont un ensemble d’objets interagissent Les objets ne communiquent plus entre eux, mais passent par le médiateur couplage faible favorisé 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 101

486. Mediator Souvent utilisé en GUI Cf. contrôleur Autre exemple : médiateur d’intégrité relationnelle pour gérer des associations bidirectionnelles 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 102

487. MVC : introduction 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Vue Vue+Modèle Vue Modèle Contrôleur (Application RAD) (possibilité de mettre plusieurs vues indépendantes) Modèle (pattern couche) (attention !) 103

488. Modèle Vue Contrôleur (arch) Problème Comment rendre le modèle (domaine métier)indépendant des vues (interface utilisateur)qui en dépendent ? Comment réduire le couplage entre modèle et vue ? Solution Insérer une couche supplémentaire (contrôleur) pour la gestion des événements et la synchronisation entre modèle et vue 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 104

489. Modèle Vue Contrôleur Modèle (logique métier)‏ Implémente le fonctionnement du système Gère les accès aux données métier Vue (interface)‏ Présente les données en cohérence avec l’état du modèle Capture et transmet les actions de l’utilisateur événements système Contrôleur Gère les changements d’état du modèle Informe le modèle des actions utilisateur Sélectionne la vue appropriée Contrôleur = médiateur 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 Modèle Vue Contrôleur 105

491. la vue se construit à partir du modèle

492. le contrôleur notifie le modèle des changements que l’utilisateur spécifie dans la vue

493. le contrôleur informe la vue que le modèle a changé et qu’elle doit se reconstruireVue Modèle Contrôleur 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 106

495. quand le modèle peut changer indépendamment du contrôleur (i.e. indépendamment des actions utilisateur)

496. le modèle informe les abonnés à l’observateur qu’il s’est modifié

497. ceux-ci prennent l’information en compte (contrôleur et vues)Vue « implements » « interface » Observateur Modèle Contrôleur « implements » 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 107

499. Les composants graphiques ont un « modèle » associé

500. Eg. Jtable / Table

501. Attention : ce « modèle » est plus un « modèle d’objet d’interface » qu’un modèle d’objet métier, il peut se mixer avec le contrôleurVoir http://java.sun.com/products/jfc/tsc/articles/architecture/ 108 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

503. la vueconnaît le modèleou non

504. le contrôleurconnaît la vueou non

505. le vueconnaît le contrôleurou non

506. « Mélange » avec le pattern Observer

507. Un ouplusieurscontrôleurs (cf. contrôleur de CU)

508. Choixd'une solution

509. dépend des caractéristiques de l'application

510. dépend des autresresponsabilités du contrôleur

511. De nombreux framework web utilisent MVC2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 109

512. Builder (Gof) Problème Que faire quand on n’a pas toutes les informations nécessaires pour construire un objet ? Que faire si la logique d’initialisation d’un objet est tellement complexe qu’elle nuit à la forte cohésion de la classe ? Solution Utiliser un objet extérieur dédié (builder) qui a pour responsabilité d’encapsuler toute la logique de construction de l’objet visé 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 110

513. Builder (suite) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 111 Director: prend en charge les différentes étapes de construction

515. Avantages par rapport à un constructeur

516. la classe a un nom

517. permet de gérer facilement plusieurs méthodes de construction avec des signatures similaires

518. plusieurs ConcreteBuilder

519. peut retourner plusieurs types d’objets

520. Un builder est en général un singleton2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 112

521. Factorymethod (GoF) Problème Comment permettre à un client de créer des objets conformes à une interface ou une classe abstraire sans savoir quelle classe instancier ? une Application veut manipuler des documents, qui répondent à une interface Document une Equipe veut gérer des Tactique… Solution Créer un objet Factory qui qui fabrique des instances conformes à cette interface ou classe abstraite 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 113

522. FactoryMethod (suite) (T. Horton, CS494) Comment Application peut-elle créer des instances de Document sans couplage avec les sous-classes ? (From Grand’s book.) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 114

523. Factory Method (suite) (T. Horton, CS494) Solution : utiliser une classe DocumentFactory pour créer différents types de documents (From Grand’s book.) 115 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

524. Factory Method : structure générale (T. Horton, CS494) discriminator : paramètre indiquant quel type de sous-classe de Product créer (From Grand’s book.) 116 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1

525. Memento (GoF) Problème Comment revenir à une version antérieure d’un travail ? Comment mettre en place un mécanisme d’annulation de modifications ? Solution Créer des objets memento qui permettent le stockage et la restauration de l’état d’un objet 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 117

526. Memento (suite) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 118

527. Décorateur Comment faire pour ajouter dynamiquement des responsabilités supplémentaires à une classe ? Créer une classe abstraite Decorator, dont les instances concrètes seront liées à une instance de la classe à étendre On peut utiliser soit le composant concret (ancienne méthode) soit le décorateur concret (nouvelle méthode) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 119

528. Décorateur 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 120 Appelle d’abord la méthode du composant concret, puis ajoute des fonctionnalités

529. State (GoF) Problème Que faire lorsque la logique qui dépend de l’état d’un objet se retrouve dispersée dans plusieurs méthodes ? Solution Déporter la logique de fonctionnement de l’objet à travers plusieurs classes extérieures qui représentent chacune un état 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 121

530. State (suite) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 122

531. Utilisation du pattern état Très utile dans les applications web Indices Attributs booléens Attributs « état » ou « statut » Dates de début et de fin Modéliser avec un diagramme d’état Implémenter avec le pattern état Bonnes propriétés pour historiser 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 123

532. Autres Metaclass Inversion de dépendance DAO 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 124

533. Metaclass Pour exprimer une relation de classification (classe / instance) au niveau des objets 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 ClasseGénérique ClasseSpécifique Attributs partagés Attributs specifiques VolGenerique VolSpecifique depart: Ville arrivée : Ville jour : [lundi, mardi…] heure : int date : DateJour pilote : String :VolSpecifique :VolGenerique date : 21/08/07 pilote : Jean départ : Paris arrivée : Lyon jour : lundi heure : 8h :VolSpecifique date : 28/08/07 pilote : Marie 125

534. Inversion de dépendance 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 126

535. Data Access Objet - DAO (J2EE) http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 ORM Object-Relational Mapping 127

537. Chain of responsability (GoF)

538. Strategy (GoF)

539. Proxy (Gof)

540. Inversion de contrôle

541. Context

542. non officiel, très utilisé dans beaucoup de frameworks

543. http://www.dotnetguru.org/articles/articlets/contextPattern/Contexte.htm

544. …2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 128

546. nécessite une représentation graphique (au minimum collaboration UML) et le codage de certaines contraintes

547. Instanciation

548. choix d’un pattern, création automatique des classes correspondantes

549. Repérage

550. assister l’utilisateur pour repérer

551. des patterns utilisés (pour les documenter)

552. des « presque patterns » (pour les faire tendre vers des patterns)

553. Exemples d’outils

554. Describe + Jbuilder

555. Objecteering (disponible à l’UFR cette année : à tester)

556. Struts Tools

557. …2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 129

558. Plan Introduction sur les patterns Patrons GRASP Design patterns 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 130

559. Conclusion On a vu assez précisément les patterns les plus généraux (GRASP) On a survolé les autres un bon programmeur doit les étudier et en connaître une cinquantaine 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 131

561. ensemble de classes qui collaborent à la réalisation d’une responsabilité qui dépasse celle de chacune

562. conception générale réutilisable pour une classe d’application donnée

563. Un framework définit

564. architecture, classes, responsabilités, flot de contrôle, etc.

565. Un framework doit être spécialisé

566. reprise de code de haut niveau (beaucoup de classes abstraites), ajout de code de spécialisation2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 132

567. Exemple de framework : STRUTS Couche IHM d’une application web gérer des sessions utilisateur, gérer des actions en fonction des requêtes HTTP Basé sur MVC Ensemble de classes à spécialiser Fabriques Contrôleurs … 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 133

568. Remerciements Olivier Aubert Yohan Welikala (Sri Lanka) Lionel Médini (2008) 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 134