CM patterns

3 156 vues

Publié le

Publié dans : Formation
0 commentaire
5 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 156
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1 087
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
5
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

CM patterns

  1. 1. Réutilisation dans les SI : patrons de conception<br />Yannick Prié<br />Département Informatique – Faculté de Sciences et Technologies<br />Université Claude Bernard Lyon 1<br />2011-2012<br />
  2. 2. Introduction : réutilisation<br /><ul><li>Constante de la conception d’outils en général
  3. 3. nécessité pratique depuis qu’il y a des outils, et que ceux-ci évoluent
  4. 4. Exemples = comment concevoir
  5. 5. une chaise ?
  6. 6. un tournevis ?
  7. 7. un bateau ?
  8. 8. un parc ?</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />2<br />
  9. 9. Réutilisation en informatique<br /><ul><li>Réutilisation de tout ce qui a été mis en place depuis les débuts de l’informatique
  10. 10. codage, réseaux, normes, principes, etc.
  11. 11. Réutilisation de code
  12. 12. composants / librairies / services
  13. 13. à utiliser / acheter / fabriquer
  14. 14. frameworks
  15. 15. à utiliser en les spécialisant
  16. 16. Réutilisation de modèles de données
  17. 17. schémas
  18. 18. Réutilisation de principes de conception
  19. 19. IHM
  20. 20. Tendance générale informatique
  21. 21. dès que quelque chose se révèle pertinent
  22. 22. abstraction / réutilisation / normalisation</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />3<br />
  23. 23. Plan<br />Introduction sur les patterns<br />Patrons GRASP <br />Design patterns<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />4<br />
  24. 24. Généralités sur les patterns<br />Pattern<br />solution classique à un problème de conception classique dans un contexte donné<br />Pattern de conception<br />structure et comportement d’une société de classes<br />description nommée d’un problème et d’une solution <br />avec conseils d’application <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />5<br />
  25. 25. Description d’un pattern<br />Nom du pattern : un ou deux mots<br /><ul><li>Permet essentiellement d’en parler
  26. 26. N’est pas significatif en soi </li></ul>Problème : quand appliquer le pattern ?<br /><ul><li>explication du problème et de son contexte
  27. 27. solution : description abstraite
  28. 28. Élément de conception, relation, responsabilités, collaboration</li></ul>Exemple d’utilisation du pattern<br />Discussion : conseils sur la façon de l’appliquer <br /><ul><li>Avantages, inconvénients, conseils d’implémentation, variantes…</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />6<br />
  29. 29. Refactoring / réingénierie<br />Définition<br />réécriture de parties de code pour obtenir des services équivalents avec une conception meilleure <br />Quand ?<br />Il existe des indicateurs de problèmes (code smells)<br />Une fois identifiés, on peut corriger le code<br />Exemples (www.refactoring.com)<br />You have a code fragment that can be grouped together.<br />Turn the fragment into a method whose name explains the purpose of the method.<br />You have a class that is in a package that contains other classes that it is not related to in function. <br />Move the class to a more relevant package. Or create a new package if required for future use. <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />7<br />
  30. 30. Plan<br />Introduction sur les patterns<br />Patrons GRASP<br />Design patterns<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />8<br />
  31. 31. Conception objet :Réduction du décalage des représentations<br /><ul><li>Décalage des représentations entre
  32. 32. la façonhumaine, conceptuelle de penser le domaine
  33. 33. « un échiquier a des cases »
  34. 34. les objets logiciels correspondants
  35. 35. un objet Echiquier contient des objets Case
  36. 36. vs. un objet Echiquier contient 4 objets 16Cases
  37. 37. vs. un objet TYR43 contient des EE25
  38. 38. Ce décalage doit être réduit au maximum
  39. 39. Les concepts du domaine évoluent peu, les objets peuvent suivre l’évolution
  40. 40. adaptation, réutilisation</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />9<br />
  41. 41. Conception objetpilotée par les responsabilités<br /><ul><li>Métaphore
  42. 42. communauté d’objets responsables qui collaborent (cf. humains) dans un projet (rôles)
  43. 43. Principe
  44. 44. penser l’organisation des composants (logiciels ou autres) en termes de responsabilités par rapport à des rôles, au sein de collaborations
  45. 45. Responsabilité
  46. 46. abstraction de comportement (contrat, obligation) par rapport à un rôle
  47. 47. une responsabilité n’est pas une méthode
  48. 48. les méthodes s’acquittent des responsabilités</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />10<br />
  49. 49. Deux catégories de responsabilités pour les objets<br /><ul><li>Savoir
  50. 50. connaître les données privées encapsulées
  51. 51. connaître les objets connexes
  52. 52. connaître les attributs à calculer ou dériver
  53. 53. Faire
  54. 54. faire quelque chose soi-même (ex. créer un autre objet, effectuer un calcul)
  55. 55. déclencher une action d’un autre objet
  56. 56. contrôler et coordonner les activités d’autres objets</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />11<br />
  57. 57. Exemple (agence de voyage)<br />Savoir<br />Réservation est responsable de la connaissance de son numéro et du voyageur associé<br />Vol est responsable de savoir s’il reste des places<br />Faire<br />Client est responsable de la construction des réservations<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />12<br />
  58. 58. Patterns GRASP<br />General ResponsabilityAssignment Software Patterns<br />Ensemble de patterns généraux d’affectation de responsabilités pour aider à la conception orientée-objet<br />raisonner objet de façon méthodique, rationnelle, explicable<br />Utile pour l’analyse et la conception<br />réalisation d’interactions avec des objets<br />Référence : Larman 2004<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />13<br />
  59. 59. 9 patterns GRASP<br />Expert en information<br />Créateur<br />Faible couplage<br />Forte cohésion<br />Contrôleur<br />Polymorphisme<br />Fabrication pure<br />Indirection<br />Protection des variations<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />4 grands principes de conception et d’évaluation : Expert, Créateur, <br />Faible couplage, Forte cohésion<br />2 outils : Fabrication pure et Indirection<br />3 applications des précédents : Contrôleur, Polymorphisme, Protection des <br />variations<br />14<br />
  60. 60. Expert (GRASP) <br />Problème<br />Quel est le principe général d’affectation des responsabilités aux objets ? <br />Solution<br />Affecter la responsabilité à l’expert en information<br />la classe qui possède les informations nécessaires pour s’acquitter de la responsabilité<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />15<br />
  61. 61. Expert : exemple<br />Bibliothèque : <br />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 ?<br />qui doit avoir la responsabilité de connaître le nombre d’exemplaires disponibles ? <br />0..*<br />emprunte<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />16<br />
  62. 62. Expert : exemple<br />Commencer avec la question<br />De quelle information a-t-on besoin pour déterminer le nombre d’exemplaires disponibles ?<br />Disponibilité de toutes les instances d’exemplaires<br />Puis <br />Qui en est responsable ?<br />Livre est l’Expert pour cette information<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />17<br />
  63. 63. Expert : exemple<br />0..*<br />emprunte<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />18<br />
  64. 64. Experts distribués<br /><ul><li>Responsabilité distribuée
  65. 65. Quand l’accomplissement d’une responsabilité nécessite de l’information répartie entre différents objets
  66. 66. La tâche globale est décomposée en sous-tâches locales
  67. 67. La responsabilité est assurée par la collaboration entre experts « locaux » avec
  68. 68. données propres
  69. 69. responsabilités correspondantes</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />19<br />
  70. 70. Expert : exemple (suite) <br />contient<br />0..*<br />concerne<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />20<br />
  71. 71. Expert : exemple (suite) <br />:Bibliothèque<br />1: n=nbLivresEnRayon()<br />1.1: n1=nbExemplaires()<br />:Exemplaire<br />1.2: n2=nbExemplaires()<br />1.1.1:d=getDispo()<br />Livres[0]:Livre<br />:Exemplaire<br />1.1.2: d=getDispo()<br />Livres[1]:Livre<br />:Exemplaire<br />1.2.1 d=getDispo()<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />21<br />
  72. 72. Expert : discussion<br /><ul><li>Lié aux principes objet
  73. 73. Encapsulation
  74. 74. les objets utilisent leurs propres informations pour mener à bien leurs tâches
  75. 75. Collaboration
  76. 76. le comportement est distribué entre les classes ayant l’information nécessaire
  77. 77. Favorise
  78. 78. Couplage faible (GRASP)
  79. 79. Systèmes robustes et maintenables
  80. 80. Forte cohésion (GRASP)
  81. 81. classes légères, faciles à comprendre, à maintenir, à réutiliser</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />22<br />
  82. 82. Expert : discussion<br /><ul><li>Le plus utilisé de tous les patterns d’attribution de responsabilités
  83. 83. Autres noms (AKA - AlsoKnown As)
  84. 84. « Mettre les responsabilités avec les données »
  85. 85. « Qui sait, fait »
  86. 86. « Faire soi-même »
  87. 87. Patterns liés (voir plus loin)
  88. 88. Faible couplage
  89. 89. Forte cohésion</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />23<br />
  90. 90. Créateur (GRASP) <br /><ul><li>Problème
  91. 91. Qui doit avoir la responsabilité de créer une nouvelle instance d’une classe donnée ?
  92. 92. Solution
  93. 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. 94. B contient, agrège ou est composé d’objets A
  95. 95. B enregistre des objets A
  96. 96. B utilise étroitement des objets A
  97. 97. B a les données d’initialisation qui seront transmises aux objets A lors de leur création
  98. 98. ie. B est un Expert en ce qui concerne la création de A</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />24<br />
  99. 99. Créateur : exemple<br />Bibliothèque : qui doit être responsable de la création de Pret? <br />contient<br />0..*<br />concerne<br />BasePret contient des Pret : elle doit les créer.<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />25<br />
  100. 100. Créateur : discussion<br /><ul><li>Guide pour attribuer une responsabilité pour la création d’objets
  101. 101. une tâche très commune en OO
  102. 102. Finalité : trouver un créateur pour qui il est nécessaire d’être connecté aux objets créés
  103. 103. favorise le Faible couplage
  104. 104. moins de dépendances de maintenance, plus d’opportunités de réutilisation
  105. 105. Pattern liés
  106. 106. Faible couplage
  107. 107. Composite
  108. 108. Fabricant</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />26<br />
  109. 109. Faible couplage (GRASP)<br />Problème<br />Comment minimiser les dépendances ?<br />Comment réduire l’impact des changements ?<br />Comment améliorer la réutilisabilité ?<br />Solution<br />Affecter les responsabilités des classes de sorte que le couplage reste faible<br />Appliquer ce principe lors de l’évaluation des solutions possibles<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />27<br />
  110. 110. Couplage ? <br /><ul><li>Définition
  111. 111. Mesure du degré auquel un élément est lié à un autre, en a connaissance ou en dépend
  112. 112. Exemples classiques de couplage de TypeX vers TypeYdans un langage OO
  113. 113. TypeX a un attribut qui réfère à TypeY
  114. 114. TypeX a une méthode qui référence TypeY
  115. 115. TypeX est une sous-classe directe ou indirecte de TypeY
  116. 116. TypeY est une interface et TypeXl’implémente
  117. 117. Les dépendances sont directement liées au couplage</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />28<br />
  118. 118. Faible couplage (suite)<br /><ul><li>Problèmes du couplage fort
  119. 119. Un changement dans une classe force à changer toutes ou la plupart des classes liées
  120. 120. Les classes prises isolément sont difficiles à comprendre
  121. 121. Réutilisation difficile : l’emploi d’une classe nécessite celui des classes dont elle dépend
  122. 122. Bénéfices du couplage faible
  123. 123. Exactement l’inverse
  124. 124. Une classe faiblement couplée a une faible dépendance aux autres classes</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />29<br />
  125. 125. Faible couplage (suite)<br /><ul><li>Principe général
  126. 126. les classes génériques et réutilisables par nature doivent avoir un faible couplage
  127. 127. Mise en œuvre
  128. 128. déterminer plusieurs possibilités pour l’affectation des responsabilités
  129. 129. comparer leurs degrés de couplage en termes de
  130. 130. nombre de relations entre les classes
  131. 131. nombre de paramètres circulant dans l’appel des méthodes
  132. 132. fréquence des messages
  133. 133. …</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />30<br />
  134. 134. Faible couplage : exemple<br />makePaiement()<br />1: create()<br />:RegistreVente<br />p : Paiement<br />2: addPaiement(p)<br />:Vente<br />makePaiement()<br />1: makePaiement()<br />:RegistreVente<br />:Vente<br />1.1. create()<br />:Paiement<br />Que choisir ?<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />31<br />
  135. 135. Faible couplage : autre exemple<br /><ul><li> Pour l’application de bibliothèque, il faut mettre l’ISBN d’un Exemplaire dans le Prêt. </li></ul>1:isbn=getISBN()<br />preter( ex: Exemplaire, …)<br />: GestionPret<br />ex:Exemplaire<br />:Pret<br />2:SetISBN(isbn)<br />Que choisir ? <br />1:SetExemplaire(ex )<br />preter( ex: Exemplaire, …)<br />: GestionPret<br />:Pret<br />1.1:getISBN()<br />ex:Exemplaire<br />Attention, réfléchir au contexte<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />32<br />
  136. 136. Faible couplage : discussion<br /><ul><li>Un principe à garder en tête pour toutes les décisions de conception
  137. 137. Ne doit pas être considéré indépendamment d’autres patterns comme Expert et Forte cohésion
  138. 138. en général, Expert soutient Faible couplage
  139. 139. Pas de mesure absolue de quand un couplage est trop fort
  140. 140. Un fort couplage n’est pas dramatique avec des éléments très stables
  141. 141. java.util par exemple</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />33<br />
  142. 142. Faible couplage : discussion (suite)<br /><ul><li>Cas extrême de faible couplage
  143. 143. des objets incohérents, complexes, qui font tout le travail
  144. 144. des objets isolés, non couplés, qui servent à stocker les données
  145. 145. peu ou pas de communication entre objets </li></ul>mauvaise conception qui va à l’encontre des principes OO (collaboration d’objets, forte cohésion)<br /><ul><li>Bref
  146. 146. un couplage modéré est nécessaire et normal pour créer des systèmes OO </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />34<br />
  147. 147. Forte cohésion (GRASP)<br /><ul><li>Problème : maintenir une complexité gérable
  148. 148. Comment s’assurer que les objets restent
  149. 149. compréhensibles ?
  150. 150. faciles à gérer ?</li></ul> (ce qui contribuera au faible couplage)<br /><ul><li>Solution
  151. 151. Attribuer les responsabilités de telle sorte que la cohésion reste forte
  152. 152. Appliquer ce principe pour évaluer les solutions possibles</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />35<br />
  153. 153. Définition cohésion<br />Cohésion (ou cohésion fonctionnelle)<br />mesure informelle de l’étroitesse des liens et de la spécialisation des responsabilités d’un élément (d’une classe)<br />relations fonctionnelles entre les différentes opérations effectuées par un élément<br />volume de travail réalisé par un élément<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />36<br />
  154. 154. Forte cohésion (suite)<br /><ul><li>Problèmes des classes à faible cohésion
  155. 155. Elle effectuent
  156. 156. trop de tâches
  157. 157. des tâches sans lien entre elles
  158. 158. Elles sont
  159. 159. difficiles à comprendre
  160. 160. difficiles à réutiliser
  161. 161. difficiles à maintenir
  162. 162. fragiles, constamment affectées par le changement
  163. 163. Bénéfices de la forte cohésion : …</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />37<br />
  164. 164. Forte cohésion (suite)<br />Une classe qui est fortement cohésive<br />a des responsabilités étroitement liées les unes aux autres<br />petit nombre de méthodes<br />fonctionnalités entre méthodes liées<br />n’effectue pas un travail gigantesque<br />Un test<br />Peut-on décrire la classe avec une seule phrase ?<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />38<br />
  165. 165. Forte cohésion : exemple<br />preter( ex: Exemplaire, …)<br />1:getISBN()<br />: GestionPret<br />ex:Exemplaire<br />:Pret<br />2:setISBN(isbn)<br /><ul><li>On rend GestionPret partiellement responsable de la mise en place des ISBN
  166. 166. GestionPret sera responsable de beaucoup d’autres fonctions</li></ul>preter(ex: Exemplaire, …)<br />1:setLivre ex )<br />: GestionPret<br />:Pret<br />1.1:getISBN()<br />ex:Exemplaire<br /><ul><li>On délègue la responsabilité de mettre l’ISBN au prêt</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />39<br />
  167. 167. Forte cohésion : discussion<br />Forte cohésion va en général de pair avec Faible couplage<br />C’est un pattern d’évaluation à garder en tête pendant toute la conception<br /><ul><li>Permet l’évaluation élément par élément (contrairement à Faible couplage)</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />40<br />
  168. 168. Forte cohésion : discussion<br />Citations<br />[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é »<br />[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 »<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />41<br />
  169. 169. Contrôleur (GRASP)<br /><ul><li>Problème
  170. 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. 171. Solution
  172. 172. Affecter cette responsabilité à une classe qui représente
  173. 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. 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 session</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />42<br />
  175. 175. Deux types de contrôleurs<br />Contrôleur Façade <br />ContrôleurS de cas d’utilisation<br />IHM<br />IHM<br />Contrôleur Facade<br />ContrôleurCU1<br />ContrôleurCU2<br />ContrôleurCU3<br />...<br />Domaine<br />Domaine<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />43<br />
  176. 176. Contrôleur Façade<br />Représente tout le système<br />exemples : ProductController, RetailInformationSystem, Switch, Router, NetworkInterfaceCard, SwitchFabric, etc.<br />À utiliser quand<br />il y a peu d’événements système <br />un seul contrôleur suffit<br />il n’est pas possible de rediriger les événements systèmes à un contrôleur alternatif<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />44<br />
  177. 177. Contrôleur de cas d’utilisation<br />Un contrôleur différent pour chaque cas d’utilisation<br />gère tous les événements d’un même cas d’utilisation<br />permet de connaître et d’analyser la séquence d’événements système et l’état de chaque scénario<br />À utiliser quand<br />les autres choix amènent à un fort couplage ou à une cohésion faible (contrôleur trop chargé - bloated)<br />il y a de nombreux événements système qui appartiennent à plusieurs processus<br />Permet de répartir la gestion entre des classes distinctes et faciles à gérer<br />Contrôleur de CU = classe artificielle<br />ce n’est pas un objet du domaine<br />au contraire d’un contrôleur Façade<br />qui correspondra par exemple à l’application complète (eg. Bibliotheque)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />45<br />
  178. 178. Contrôleur<br /><ul><li>Principes à bien comprendre : idéalement
  179. 179. un contrôleur est un objet qui ne fait rien
  180. 180. reçoit les événements système
  181. 181. délègue aux objets dont la responsabilité est de les traiter
  182. 182. il se limite aux tâches de contrôle et de coordination
  183. 183. vérification de la séquence des événements système
  184. 184. appel des méthodes ad hoc des autres objets
  185. 185. il peut gérer des fonctionnalités transversales
  186. 186. eg authentification
  187. 187. Règle d’or
  188. 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 domaine</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />46<br />
  189. 189. Contrôleur<br />Mise en œuvre<br />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<br />À l’analyse/conception, des classes contrôleur sont mises en place pour prendre en charge ces opérations<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />47<br />
  190. 190. Contrôleur : exemple<br />Pour la gestion d’une bibliothèque, qui doit être contrôleur pour l’opération système emprunter ?<br />Deux possibilités<br />Le contrôleur représente lesystème global <br />:Bibliothèque<br />Le contrôleur ne gère que lesopérations système liées aucas d’utilisation emprunter<br />:GestionPret<br />La décision d’utiliser l’une ou l’autre solution dépend d’autres facteurs liés à la cohésion et au couplage<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />48<br />
  191. 191. Contrôleur trop chargé (pas bon)<br /><ul><li>Pas de focus, prend en charge de nombreux domaines de responsabilité
  192. 192. un seul contrôleur reçoit tous les événements système
  193. 193. le contrôleur effectue la majorité des tâches nécessaires pour répondre aux événements système
  194. 194. un contrôleur doit déléguer à d’autres objets les tâches à effectuer
  195. 195. il a beaucoup d’attributs et gère des informations importantes du système ou du domaine
  196. 196. ces informations doivent être distribuées dans les autres objets
  197. 197. ou doivent être des duplications d’informations trouvées dans d’autres objets
  198. 198. Solution
  199. 199. ajouter des contrôleurs
  200. 200. concevoir des contrôleurs dont la priorité est de déléguer</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />49<br />
  201. 201. Remarque : couche présentation<br />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<br />c’est la responsabilité de la couche domaine ou application<br />onPretLivre()<br />onPretLivre()<br />:JFramePret<br />: JFramePret<br />1:emprunterItem()<br />1:valider()<br />1.1:valider()<br />:GestionPret<br />:Abonné<br />:Abonné<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />50<br />
  202. 202. Contrôleur : discussion<br /><ul><li>Avantages
  203. 203. Meilleur potentiel de réutilisation
  204. 204. permet de réaliser des composants d’interface enfichables
  205. 205. « porte d’entrée » vers les objets de la couche domaine
  206. 206. la rend indépendante des types d’interface (Web, client riche, simulateur de test…)
  207. 207. Niveau d’indirection matérialisant la séparation Modèle-Vue
  208. 208. Brique de base pour une conception modulaire
  209. 209. Meilleure « architecturation » des CU
  210. 210. Patterns liés
  211. 211. Indirection, Couches, Façade, Fabrication pure, Commande</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />51<br />
  212. 212. Polymorphisme (GRASP)<br /><ul><li>Problème
  213. 213. Comment gérer des alternatives dépendantes des types ?
  214. 214. Comment créer des composants logiciels « enfichables » ?
  215. 215. Solution
  216. 216. Affecter les responsabilités aux types (classes) pour lesquels le comportement varie
  217. 217. Utiliser des opérations polymorphes
  218. 218. Polymorphisme
  219. 219. Donner le même nom à des services dans différents objets
  220. 220. Lier le « client » à un supertype commun</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />52<br />
  221. 221. Polymorphisme (GRASP)<br /><ul><li>Principe
  222. 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. 223. L’opération nécessite à la fois des informations et un comportement particuliers
  224. 224. Mise en œuvre
  225. 225. Utiliser des classes abstraites
  226. 226. Pour définir les autres comportements communs
  227. 227. S’il n’y a pas de contre-indication (héritage multiple)
  228. 228. Utiliser des interfaces
  229. 229. Pour spécifier les opérations polymorphes
  230. 230. Utiliser les deux (CA implémentant des interfaces)
  231. 231. Fournit un point d’évolution pour d’éventuels cas particuliers futurs</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />53<br />
  232. 232. Polymorphisme : exemple<br /><ul><li>Bibliothèque : qui doit être responsable de savoir si un exemplaire est disponible ? </li></ul>1<br />*<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />54<br />
  233. 233. Polymorphisme : exemple<br /><ul><li>Bibliothèque : qui doit être responsable de savoir si un exemplaire est disponible ?
  234. 234. Nouvelle situation : un Exemplaire est une sort d’Artefact</li></ul>1<br />*<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />55<br />
  235. 235. Polymorphisme : discussion<br /><ul><li>Autre solution (mauvaise)
  236. 236. Utiliser une logique conditionnelle (test sur le type d’un objet) au niveau du client
  237. 237. Nécessite de connaître toutes les variations de type
  238. 238. Augmente le couplage
  239. 239. Avantages du polymorphisme
  240. 240. Évolutivité
  241. 241. Points d’extension requis par les nouvelles variantes faciles à ajouter (nouvelle sous-classe)
  242. 242. Couplage faible avec le client
  243. 243. Introduire de nouvelles implémentations n’affecte pas les clients
  244. 244. Patterns liés
  245. 245. Protection des variations, Faible couplage</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />56<br />
  246. 246. Fabrication pure (GRASP) <br /><ul><li>Problème
  247. 247. Que faire
  248. 248. pour respecter le Faible couplage et la Forte cohésion
  249. 249. quand aucun concept du monde réel (objets du domaine) n’offre de solution satisfaisante ?
  250. 250. ie le modèle du domaine ne fournit pas de classe adéquate
  251. 251. Solution
  252. 252. affecter un ensemble fortement cohésif à une classe artificielle ou de commodité, qui ne représente pas un concept du domaine
  253. 253. entité fabriquée de toutes pièces</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />57<br />
  254. 254. Fabrication pure (GRASP) <br /><ul><li>Exemple typique de besoin de fabrication pure
  255. 255. Utiliser l’Expert en information
  256. 256. lui attribuerait trop de responsabilités (contrarie Forte cohésion)
  257. 257. le lierait à beaucoup d’autres objets (contrarie Faible couplage)
  258. 258. Mise en œuvre
  259. 259. Déterminer les fonctionnalités « annexes » de l’Expert en information
  260. 260. Les regrouper dans des objets
  261. 261. aux responsabilités limitées (fortement cohésifs)
  262. 262. aussi génériques que possible (réutilisables)
  263. 263. Nommer ces objets
  264. 264. pour permettre d’identifier leurs responsabilités fonctionnelles
  265. 265. en utilisant éventuellement la terminologie du domaine
  266. 266. en général difficile</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />58<br />
  267. 267. Fabrication pure : exemple<br /><ul><li>Problème
  268. 268. les instances de Prêt doivent être enregistrées dans une BD
  269. 269. Solution initiale (d’après Expert)
  270. 270. Prêt a cette responsabilité
  271. 271. cela nécessite
  272. 272. un grand nombre d’opérations de BD Prêt devient donc non cohésif
  273. 273. de lier Prêt à une BDle couplage augmente pour Prêt</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />59<br />
  274. 274. Fabrication pure : exemple (suite)<br /><ul><li>Constat
  275. 275. l’enregistrement d’objets dans une BD est une tâche générique utilisable par de nombreux objets
  276. 276. pas de réutilisation, beaucoup de duplication
  277. 277. Solution avec Fabrication pure
  278. 278. créer une classe artificielle GestionArchivage
  279. 279. Avantages
  280. 280. Gains pour Prêt
  281. 281. Forte cohésion et Faible couplage
  282. 282. Conception de GestionArchivage« propre »
  283. 283. relativement cohésif, générique et réutilisable</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />60<br />
  284. 284. Fabrication pure : discussion<br /><ul><li>Choix des objets pour la conception
  285. 285. décomposition représentationnelle (à partir des concepts du domaine)
  286. 286. conforme au principes de base de l’OO
  287. 287. encapsulation données / traitements
  288. 288. réduction du décalage des représentations entre le réel et le modèle
  289. 289. décomposition comportementale (Fabrication pure)
  290. 290. sortes d’objets « centré-fonction » qui rendent des services transverses dans un projet (POA)
  291. 291. Ne pas abuser des Fabrications pures</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />61<br />
  292. 292. Fabrication pure : discussion<br /><ul><li>Règle d’or
  293. 293. Concevoir des objets Fabrication pure en pensant à leur réutilisabilité
  294. 294. s’assurer qu’ils ont des responsabilités limitées et cohésives
  295. 295. Avantages
  296. 296. Supporte Faible couplage et Forte cohésion
  297. 297. Améliore la réutilisabilité
  298. 298. Patterns liés
  299. 299. Faible couplage, Forte cohésion, Adaptateur, Observateur, Visiteur
  300. 300. Paradigme lié
  301. 301. Programmation Orientée Aspects</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />62<br />
  302. 302. Indirection (GRASP) <br /><ul><li>Problème
  303. 303. Où affecter une responsabilité pour éviter le couplage entre deux entités (ou plus)
  304. 304. de façon à diminuer le couplage (objets dans deux couches différentes) ?
  305. 305. de façon à favoriser la réutilisabilité (utilisation d’une API externe) ?
  306. 306. Solution
  307. 307. Créer un objet qui sert d’intermédiaire entre d’autres composants ou services
  308. 308. l’intermédiaire crée une indirection entre les composants
  309. 309. l’intermédiaire évite de les coupler directement</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />63<br />
  310. 310. Indirection (GRASP) <br /><ul><li>Utilité
  311. 311. Réaliser des adaptateurs, façades, etc. (pattern Protection des variations) qui s’interfacent avec des systèmes extérieurs
  312. 312. Exemples : proxys, DAO (Data Access Object), ORB (Object Request Broker)
  313. 313. Réaliser des inversions de dépendances entre packages
  314. 314. Cf. TD sur les compagnies aériennes
  315. 315. Mise en œuvre
  316. 316. Utilisation d’objets du domaine
  317. 317. Création d’objets
  318. 318. Classes : cf. Fabrication pure
  319. 319. Interfaces : cf. Fabrication pure + Polymorphisme</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />64<br />
  320. 320. Indirection : exemple<br /><ul><li>Bibliothèque : accès à un système de stockage propriétaire</li></ul>:Prêt<br />« actor »<br />:SystèmeStockage<br />enregistrePrêt()<br />xxx()<br />Communication réseau (socket TCP)<br />:AdaptateurStockage<br />:Prêt<br />« actor »<br />:SystèmeStockage<br />enregistrePrêt()<br />insertion()<br />xxx()<br />- Méthode stable<br />- Reste dans la couche métier<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />65<br />
  321. 321. Indirection : discussion<br /><ul><li>Remarques
  322. 322. Beaucoup de Fabrications pures sont créées pour des raisons d’indirection
  323. 323. Objectif principal de l’indirection : faible couplage
  324. 324. Adage (et contre adage)
  325. 325. « En informatique, on peut résoudre la plupart des problèmes en ajoutant un niveau d’indirection » (David Wheeler)
  326. 326. « En informatique, on peut résoudre la plupart des problèmes de performance en supprimant un niveau d’indirection »
  327. 327. Patterns liés
  328. 328. GRASP : Fabrication pure, Faible couplage, Protection des variations
  329. 329. GoF : Adaptateur, Façade, Observateur…</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />66<br />
  330. 330. Protection des variations (GRASP)<br /><ul><li>Problème
  331. 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. 332. Solution
  333. 333. Identifier les points de variation ou d’instabilité prévisibles
  334. 334. Affecter les responsabilités pour créer une interface (au sens large) stable autour d’eux (indirection)</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />67<br />
  335. 335. Protection des variations (GRASP)<br /><ul><li>Mise en œuvre
  336. 336. Cf. patterns précédents (Polymorphisme, Fabrication pure, Indirection)
  337. 337. Exemples de mécanismes de PV
  338. 338. Encapsulation des données, brokers, machines virtuelles…
  339. 339. Exercice
  340. 340. Point de variation = stockage de Prêt dans plusieurs systèmes différents
  341. 341. Utiliser Indirection + Polymorphisme</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />68<br />
  342. 342. Protection des variations : discussion<br /><ul><li>Ne pas se tromper de combat
  343. 343. Prendre en compte obligatoirement les points de variation
  344. 344. Nécessaires car identifiés dans le système existant ou dans les besoins
  345. 345. Gérer sagement les points d’évolution
  346. 346. Points de variation futurs, « spéculatifs » : à identifier (ne figurent pas dans les besoins)
  347. 347. Pas obligatoirement à implémenter
  348. 348. Le coût de prévision et de protection des points d’évolution peut dépasser celui d’une reconception
  349. 349. Ne pas passer trop de temps à préparer des protections qui ne serviront jamais</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />69<br />
  350. 350. Protection des variations : discussion<br />Différents niveaux de sagesse<br />le novice conçoit fragile<br />le meilleur programmeur conçoit tout de façon souple et en généralisant systématiquement<br />l’expert sait évaluer les combats à mener<br />Avantages<br />Masquage de l’information<br />Diminution du couplage<br />Diminution de l’impact ou du coût du changement<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />70<br />
  351. 351. Ne pas parler aux inconnus<br /><ul><li>Cas particulier de Protection des variations
  352. 352. protection contre les variations liées aux évolutions de structure des classes du système
  353. 353. Problème
  354. 354. Comment éviter de connaître la structure d’autres objets indirectement ?
  355. 355. Si un client utilise un service ou obtient de l’information d’un objet indirect (inconnu), comment le faire sans couplage ?
  356. 356. Solution
  357. 357. Éviter de connaître la structure d’autres objets indirectement
  358. 358. se limiter aux objets connus directement
  359. 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 dernier</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />71<br />
  360. 360. Ne pas parler aux inconnus (suite)<br /><ul><li>Cas général à éviter a.getB().getC().getD().methodeDeD();
  361. 361. A est dépendant de B, C et D
  362. 362. si l’une des méthodes de la chaîne disparaît, A devient inutilisable
  363. 363. tout changement de methodeDeD() peut avoir une conséquence sur A
  364. 364. Préconisation (« Loi de Demeter »)
  365. 365. Depuis une méthode, n’envoyer des messages qu’aux objets suivants
  366. 366. l’objet this(self)
  367. 367. un paramètre de la méthode courante
  368. 368. un attribut de this
  369. 369. un élément d’une collection qui est un attribut de this
  370. 370. un objet créé à l’intérieur de la méthode
  371. 371. Implication
  372. 372. ajout d’opérations dans les objets directs pour servir d’opérations intermédiaires</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />72<br />
  373. 373. Ne pas parler aux inconnus : exemple<br />Comment implémenter disponible() dans GestionPret ?<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />nbExDispo():Int<br />73<br />
  374. 374. Principe DRY / DIE<br />DRY : Don't Repeat Yourself <br />DIE : Duplication is Evil<br />Principe général de conception / programmation<br />"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system"<br />S’applique à tout le système : code, configuration, modèles, documentation, etc.<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />74<br />
  375. 375. Les patterns GRASP et les autres<br />D’une certaine manière, tous les autres patterns sont<br />des applications,<br />des spécialisations,<br />des utilisations conjointes<br /> des 9 patterns GRASP, qui sont les plus généraux.<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />75<br />
  376. 376. Plan<br />Introduction sur les patterns<br />Patrons GRASP <br />Design patterns<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />76<br />
  377. 377. Généralités<br />Origine dans l’architecture <br />ouvrages de Christopher Alexander (77)<br />http://www.math.utsa.edu/sphere/salingar/patterninteractive-french.html<br />Propriétés<br />pragmatisme<br />solutions existantes et éprouvées<br />récurrence<br />bonnes manières de faire éprouvées<br />générativité<br />comment et quand appliquer, indépendance au langage de programmation<br />émergence<br />la solution globale émerge de l’application d’un ensemble de patrons<br />Exemples : entrée, couloir<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />77<br />
  378. 378. Types de patrons informatiques<br /><ul><li>Patrons de conception
  379. 379. architecture
  380. 380. conception de systèmes
  381. 381. conception
  382. 382. interaction de composants
  383. 383. comportement
  384. 384. structure
  385. 385. création
  386. 386. idiomes de programmation
  387. 387. techniques, styles spécifiques à un langage
  388. 388. Patrons d’analyse
  389. 389. Patrons d’organisation
  390. 390. … </li></ul>(O. Aubert)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />78<br />
  391. 391. Références<br /><ul><li>Ouvrage du « Gang of Four » (GoF)
  392. 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. 393. Plus orienté architecture
  394. 394. Martin Fowler (2002) Patterns of Enterprise Application Architecture, Addison Wesley
  395. 395. Deux ouvrages récents en français
  396. 396. 23 patterns de conception / JAVA
  397. 397. Sites
  398. 398. http://www.hillside.net/patterns
  399. 399. http://java.sun.com/blueprints/corej2eepatterns/
  400. 400. …</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />79<br />
  401. 401. Éléments d’un patron<br /><ul><li>Nom
  402. 402. Évocateur, référence concise
  403. 403. Problème
  404. 404. Objectifs que le patron cherche à atteindre
  405. 405. Contexte initial
  406. 406. Comment le problème survient
  407. 407. Quand la solution fonctionne
  408. 408. Forces/contraintes
  409. 409. Forces et contraintes interagissant au sein du contexte
  410. 410. Détermination des compromis
  411. 411. Solution
  412. 412. Comment mettre en œuvre la solution ?
  413. 413. Point de vue statique (structure) et dynamique (interactions)
  414. 414. Variantes de solutions</li></ul>(O. Aubert)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />80<br />
  415. 415. Éléments d’un patron (suite)<br /><ul><li>Exemples
  416. 416. Exemples d’applications
  417. 417. Contexte résultant
  418. 418. Description du contexte résultant de l’application du patron au contexte initial
  419. 419. Conséquences positives et négatives
  420. 420. Justification
  421. 421. Raisons fondamentales conduisant à l’utilisation du patron
  422. 422. Réflexions sur la qualité du patron
  423. 423. Patrons associés
  424. 424. Similaires ou possédant des contextes initial ou résultant proches
  425. 425. Utilisations connues
  426. 426. Exemples d’applications réels</li></ul>(O. Aubert)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />81<br />
  427. 427. Les patrons ne sont pas<br />Limités au domaine informatique<br />Des idées nouvelles<br />Des solutions qui n’ont fonctionné qu’une seule fois<br />Des principes abstraits ou des heuristiques<br />Une panacée<br />(O. Aubert)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />82<br />
  428. 428. Les patrons sont<br />(O. Aubert)<br /><ul><li>Des solutions éprouvées à des problèmes récurrents
  429. 429. Spécifiques au domaine d’utilisation
  430. 430. Rien d’exceptionnel pour les experts d’un domaine
  431. 431. Une forme littéraire pour documenter des pratiques
  432. 432. Un vocabulaire partagé pour discuter de problèmes
  433. 433. Un moyen efficace de réutiliser et partager de l’expérience</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />83<br />
  434. 434. Remarque : anti-patrons<br /><ul><li>Erreurs courantes de conception documentées
  435. 435. Caractérisés par
  436. 436. lenteur du logiciel
  437. 437. coûts de réalisation ou de maintenance élevés
  438. 438. comportements anormaux
  439. 439. présence de bogues.
  440. 440. Exemples
  441. 441. Action à distance
  442. 442. Emploi massif de variables globales, fort couplage
  443. 443. Coulée de lave
  444. 444. Partie de code encore immature mise en production, forçant la lave à se solidifier en empêchant sa modification
  445. 445. …</li></ul>(wikipedia)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />84<br />
  446. 446. Présentation(Application)DomaineServiceMiddlewareFondation<br />Pattern Couches<br />Couche <br />classiques<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />85<br />
  447. 447. Pattern Multi-couches<br /><ul><li>Idée
  448. 448. organiser le systèmes en différentes couches
  449. 449. Principes
  450. 450. chaque couche communique seulement avec une couche située en dessous
  451. 451. chaque couche contient un ou plusieurs packages aux interfaces bien définies
  452. 452. une couche du dessus voit une couche du dessous comme un ensemble de services
  453. 453. deux couches peuvent fournir des mêmes fonctionnalités, mais à des niveaux d’abstraction différents (eg. couches réseaux)
  454. 454. l’interface graphique doit obligatoirement se trouver dans une couche spécifique
  455. 455. la couche sous la couche IHM fournit les fonctions déterminées par les cas d’utilisation (cf. Contrôleur)
  456. 456. les couches du bas fournissent des services généraux (e.g. communication réseau, accès base de données, etc.)
  457. 457. les couches peuvent tourner sur des machines différentes , auquel cas on parlera de tiers (architectures multi-tiers)</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />86<br />
  458. 458. Architecture multi-couches : apports<br /><ul><li>Diviser et conquérir
  459. 459. Les couches peuvent être conçues indépendamment les unes des autres
  460. 460. Réduction du couplage
  461. 461. Pas de dépendances des couches basses aux couches hautes
  462. 462. Plus de flexibilité
  463. 463. Possibilité d’ajouter des fonctionnalités au-dessus de services bas niveau, ou de remplacer des couches hautes
  464. 464. Conception portable
  465. 465. isoler les modules interdépendants dans une couche
  466. 466. Conception plus facile à tester
  467. 467. Les couches peuvent être testées indépendamment les unes des autres
  468. 468. Permet de concevoir défensivement
  469. 469. Les API des couches sont le lien naturel où faire des tests rigoureux </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />87<br />
  470. 470. Adapter - Adaptateur (GoF)<br />Problème<br />comment un client peut-il utiliser une classe existante suivant une interface qu’il définit lui-même ?<br />Solution<br />mettre en place un adapter qui fournira l’interface désirée en utilisant les services de la classe existante <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />88<br />
  471. 471. Adaptateur de classe<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />89<br />
  472. 472. Adaptateur d’objet<br />Si on n’a pas d’interface<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />90<br />
  473. 473. Façade (Gof)<br />Problème<br />comment offrir une manière simple d’utiliser un ensemble de services rendus par plusieurs classes d’un package ?<br />comment donner une interface bien conçue à un package mal conçu ?<br />Solution<br />utiliser une classe Façade qui fournit une interface<br />simplifiant l’emploi d’un sous-système (pour les tâches les plus communes)<br />offrant un accès bien défini et correspondant aux besoins des clients<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />91<br />
  474. 474. Client Classes<br />Subsystem classes<br />Façade (GoF) : solution<br />Facade<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />92<br />
  475. 475. Composite (GoF)<br />Problème<br />Comment modéliser des compositions d’éléments en gérant des comportements de façon unifiée<br />Solution<br />Utiliser une structure composite permettant aux clients de traiter de façon uniforme des objets individuels et des composition d’objets <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />93<br />
  476. 476. Composite (GoF)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br /><<abstract>><br />94<br />
  477. 477. Composite (exercice)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Comment implémenter les divers compteNoeuds() ?<br />95<br /><<abstract>><br />
  478. 478. Singleton (GoF)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Problème<br />Comment garantir qu’une classe a une instance unique et comment fournir un point d’accès unique et global à cette instance ?<br />Solution<br />Créer une classe singleton<br />96<br />
  479. 479. Singleton (GoF)<br />-ClasseSingleton instanceUnique<br />-singletonData<br />UML<br />Utiliser une méthode statique de la classe qui retourne l’instance<br />Constructeur privé ou protégé<br />Utilisation par des threads : attention !<br />1<br />ClasseSingleton<br />-Singleton()<br />+getInstance() : ClasseSingleton<br />+getSingletonData()<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />public staticgetInstance() {<br /> if (instanceUnique == NULL) {<br />instanceUnique = new ClasseSingleton() ; <br /> // …<br /> return instanceUnique ;<br />} <br />97<br />
  480. 480. Observer - Observateur (GoF)<br />Problème<br />Comment des clients qui dépendent d’un objet peuvent-il savoir que l’état de cet objet a changé ?<br />Comment avoir un couplage faible entre cet objet et les clients ?<br />Solution<br />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. <br />Donner la responsabilité <br />au souscripteur de demander la notification<br />au diffuseur de prévenir les clients concernés<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />98<br />
  481. 481. Observateur<br /><ul><li>Définir une interface « Souscripteur » ou « Observer »
  482. 482. Faire implémenter cette interface à chaque souscripteur
  483. 483. Le diffuseur peut enregistrer dynamiquement les souscripteurs intéressés par un événement et le leur signaler</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Subject : souvent classe abstraite<br />Observer : interface<br />99<br />
  484. 484. Observateur (suite)<br />Souvent utilisé pour les IHM (voir pattern MVC)<br />Autres noms<br />Diffusion-souscription<br />Modèle de délégation d’événements<br />Observateur est derrière le modèle événementiel en Java<br />java.util.Observer, java.util.Observable<br />Rq : si impossibilité de spécialiser Observable<br /> attacher une sous-classe d’Observable à l’objet diffuseur<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />100<br />
  485. 485. Mediator (GoF)<br />Problème<br />Que faire lorsque la trop grande complexité d’une distribution de responsabilités entre objets nécessite une autorité centrale ?<br />Solution<br />Définir un objet médiateur qui encapsule la façon dont un ensemble d’objets interagissent <br />Les objets ne communiquent plus entre eux, mais passent par le médiateur <br />couplage faible favorisé<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />101<br />
  486. 486. Mediator<br />Souvent utilisé en GUI <br />Cf. contrôleur <br />Autre exemple : médiateur d’intégrité relationnelle<br />pour gérer des associations bidirectionnelles<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />102<br />
  487. 487. MVC : introduction<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Vue<br />Vue+Modèle<br />Vue<br />Modèle<br />Contrôleur<br />(Application<br />RAD)<br />(possibilité de <br />mettre plusieurs <br />vues indépendantes) <br />Modèle<br />(pattern couche) <br />(attention !)<br />103<br />
  488. 488. Modèle Vue Contrôleur (arch)<br />Problème<br />Comment rendre le modèle (domaine métier)indépendant des vues (interface utilisateur)qui en dépendent ?<br />Comment réduire le couplage entre modèle et vue ?<br />Solution<br />Insérer une couche supplémentaire (contrôleur) pour la gestion des événements et la synchronisation entre modèle et vue<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />104<br />
  489. 489. Modèle Vue Contrôleur<br />Modèle (logique métier)‏<br />Implémente le fonctionnement du système<br />Gère les accès aux données métier<br />Vue (interface)‏<br />Présente les données en cohérence avec l’état du modèle<br />Capture et transmet les actions de l’utilisateur <br />événements système<br />Contrôleur<br />Gère les changements d’état du modèle<br />Informe le modèle des actions utilisateur<br />Sélectionne la vue appropriée<br />Contrôleur = médiateur<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />Modèle<br />Vue<br />Contrôleur<br />105<br />
  490. 490. Modèle Vue Contrôleur (suite)<br /><ul><li>Version modèle passif
  491. 491. la vue se construit à partir du modèle
  492. 492. le contrôleur notifie le modèle des changements que l’utilisateur spécifie dans la vue
  493. 493. le contrôleur informe la vue que le modèle a changé et qu’elle doit se reconstruire</li></ul>Vue<br />Modèle<br />Contrôleur<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />106<br />
  494. 494. Modèle Vue Contrôleur (suite)<br /><ul><li>Version modèle actif
  495. 495. quand le modèle peut changer indépendamment du contrôleur (i.e. indépendamment des actions utilisateur)
  496. 496. le modèle informe les abonnés à l’observateur qu’il s’est modifié
  497. 497. ceux-ci prennent l’information en compte (contrôleur et vues)</li></ul>Vue<br />« implements »<br />« interface »<br />Observateur<br />Modèle<br />Contrôleur<br />« implements »<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />107<br />
  498. 498. Modèle Vue Contrôleur (suite)<br />http://java.sun.com/blueprints/patterns/MVC-detailed.html<br /><ul><li>MVC Java Swing
  499. 499. Les composants graphiques ont un « modèle » associé
  500. 500. Eg. Jtable / Table
  501. 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ôleur</li></ul>Voir http://java.sun.com/products/jfc/tsc/articles/architecture/<br />108<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  502. 502. Modèle Vue Contrôleur (suite)<br /><ul><li>Différentes versions
  503. 503. la vueconnaît le modèleou non
  504. 504. le contrôleurconnaît la vueou non
  505. 505. le vueconnaît le contrôleurou non
  506. 506. « Mélange » avec le pattern Observer
  507. 507. Un ouplusieurscontrôleurs (cf. contrôleur de CU)
  508. 508. Choixd'une solution
  509. 509. dépend des caractéristiques de l'application
  510. 510. dépend des autresresponsabilités du contrôleur
  511. 511. De nombreux framework web utilisent MVC</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />109<br />
  512. 512. Builder (Gof)<br />Problème<br />Que faire quand on n’a pas toutes les informations nécessaires pour construire un objet ?<br />Que faire si la logique d’initialisation d’un objet est tellement complexe qu’elle nuit à la forte cohésion de la classe ?<br />Solution<br />Utiliser un objet extérieur dédié (builder) qui a pour responsabilité d’encapsuler toute la logique de construction de l’objet visé <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />110<br />
  513. 513. Builder (suite)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />111<br />Director: prend en charge les <br />différentes étapes de construction<br />
  514. 514. Builder (suite)<br /><ul><li>Aussi appelé « Fabrique concrète »
  515. 515. Avantages par rapport à un constructeur
  516. 516. la classe a un nom
  517. 517. permet de gérer facilement plusieurs méthodes de construction avec des signatures similaires
  518. 518. plusieurs ConcreteBuilder
  519. 519. peut retourner plusieurs types d’objets
  520. 520. Un builder est en général un singleton</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />112<br />
  521. 521. Factorymethod (GoF)<br />Problème<br />Comment permettre à un client de créer des objets conformes à une interface ou une classe abstraire sans savoir quelle classe instancier ?<br />une Application veut manipuler des documents, qui répondent à une interface Document <br />une Equipe veut gérer des Tactique…<br />Solution <br />Créer un objet Factory qui qui fabrique des instances conformes à cette interface ou classe abstraite<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />113<br />
  522. 522. FactoryMethod (suite)<br />(T. Horton, CS494)<br />Comment Application peut-elle créer des instances de Document sans couplage avec les sous-classes ? <br />(From Grand’s book.)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />114<br />
  523. 523. Factory Method (suite)<br />(T. Horton, CS494)<br />Solution : utiliser une classe DocumentFactory pour créer différents types de documents<br />(From Grand’s book.)<br />115<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  524. 524. Factory Method : structure générale<br />(T. Horton, CS494)<br />discriminator : paramètre indiquant quel type de sous-classe de Product créer <br />(From Grand’s book.)<br />116<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />
  525. 525. Memento (GoF)<br />Problème<br />Comment revenir à une version antérieure d’un travail ? Comment mettre en place un mécanisme d’annulation de modifications ?<br />Solution<br />Créer des objets memento qui permettent le stockage et la restauration de l’état d’un objet<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />117<br />
  526. 526. Memento (suite)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />118<br />
  527. 527. Décorateur<br />Comment faire pour ajouter dynamiquement des responsabilités supplémentaires à une classe ?<br />Créer une classe abstraite Decorator, dont les instances concrètes seront liées à une instance de la classe à étendre<br />On peut utiliser <br />soit le composant concret (ancienne méthode) <br />soit le décorateur concret (nouvelle méthode)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />119<br />
  528. 528. Décorateur<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />120<br />Appelle d’abord la méthode<br /> du composant concret, puis ajoute des fonctionnalités <br />
  529. 529. State (GoF)<br />Problème<br />Que faire lorsque la logique qui dépend de l’état d’un objet se retrouve dispersée dans plusieurs méthodes ?<br />Solution<br />Déporter la logique de fonctionnement de l’objet à travers plusieurs classes extérieures qui représentent chacune un état<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />121<br />
  530. 530. State (suite)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />122<br />
  531. 531. Utilisation du pattern état<br />Très utile dans les applications web<br />Indices<br />Attributs booléens<br />Attributs « état » ou « statut »<br />Dates de début et de fin<br />Modéliser avec un diagramme d’état<br />Implémenter avec le pattern état<br />Bonnes propriétés pour historiser<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />123<br />
  532. 532. Autres<br />Metaclass<br />Inversion de dépendance<br />DAO<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />124<br />
  533. 533. Metaclass<br />Pour exprimer une relation de classification (classe / instance) au niveau des objets<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />ClasseGénérique<br />ClasseSpécifique<br />Attributs partagés<br />Attributs specifiques<br />VolGenerique<br />VolSpecifique<br />depart: Ville<br />arrivée : Ville<br />jour : [lundi, mardi…]<br />heure : int<br />date : DateJour<br />pilote : String<br />:VolSpecifique<br />:VolGenerique<br />date : 21/08/07<br />pilote : Jean<br />départ : Paris<br />arrivée : Lyon<br />jour : lundi<br />heure : 8h<br />:VolSpecifique<br />date : 28/08/07<br />pilote : Marie<br />125<br />
  534. 534. Inversion de dépendance<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />126<br />
  535. 535. Data Access Objet - DAO (J2EE)<br />http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />ORM <br />Object-Relational Mapping<br />127<br />
  536. 536. Autres patterns<br /><ul><li>Bridge (GoF)
  537. 537. Chain of responsability (GoF)
  538. 538. Strategy (GoF)
  539. 539. Proxy (Gof)
  540. 540. Inversion de contrôle
  541. 541. Context
  542. 542. non officiel, très utilisé dans beaucoup de frameworks
  543. 543. http://www.dotnetguru.org/articles/articlets/contextPattern/Contexte.htm
  544. 544. …</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />128<br />
  545. 545. IDE « orientés » Design patterns<br /><ul><li>Fournir une aide à l’instanciation ou au repérage de patterns
  546. 546. nécessite une représentation graphique (au minimum collaboration UML) et le codage de certaines contraintes
  547. 547. Instanciation
  548. 548. choix d’un pattern, création automatique des classes correspondantes
  549. 549. Repérage
  550. 550. assister l’utilisateur pour repérer
  551. 551. des patterns utilisés (pour les documenter)
  552. 552. des « presque patterns » (pour les faire tendre vers des patterns)
  553. 553. Exemples d’outils
  554. 554. Describe + Jbuilder
  555. 555. Objecteering (disponible à l’UFR cette année : à tester)
  556. 556. Struts Tools
  557. 557. …</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />129<br />
  558. 558. Plan<br />Introduction sur les patterns<br />Patrons GRASP <br />Design patterns<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />130<br />
  559. 559. Conclusion<br />On a vu assez précisément les patterns les plus généraux (GRASP)<br />On a survolé les autres<br />un bon programmeur doit les étudier et en connaître une cinquantaine<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />131<br />
  560. 560. Framework<br /><ul><li>Définition
  561. 561. ensemble de classes qui collaborent à la réalisation d’une responsabilité qui dépasse celle de chacune
  562. 562. conception générale réutilisable pour une classe d’application donnée
  563. 563. Un framework définit
  564. 564. architecture, classes, responsabilités, flot de contrôle, etc.
  565. 565. Un framework doit être spécialisé
  566. 566. reprise de code de haut niveau (beaucoup de classes abstraites), ajout de code de spécialisation</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />132<br />
  567. 567. Exemple de framework : STRUTS<br />Couche IHM d’une application web<br />gérer des sessions utilisateur, gérer des actions en fonction des requêtes HTTP<br />Basé sur MVC<br />Ensemble de classes à spécialiser<br />Fabriques<br />Contrôleurs<br />… <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />133<br />
  568. 568. Remerciements<br />Olivier Aubert<br />Yohan Welikala (Sri Lanka)<br />Lionel Médini (2008)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 <br />134<br />

×