Design Patterns (2003)

1. 3012 Mise en oeuvre des DesignPatterns sur une étude de casPascal Roques Consultant senior et formateur 2. IntroductionPrésentations Programme 3. Présentations• Intervenant : Pascal Roques • Consultant senior chez • Responsable des formations autour de l’analyse et de la conception objet avec UML • Auteur de 3 ouvrages sur UML parus chez Eyrolles : UML en action - 2e édition UML par la pratique UML - Modéliser un site De lanalyse des besoins Cours et exercices Java et C# à la conception en Javae-commerce- 2ème éditionLes Cahiers du Programmeur 4. Notre programme• 1. Introduction• 2. Les Design Patterns• 3. Analyse de l’étude de cas (Together®)• 4. Application des Design Patterns (Together®)• 5. Conclusion 5. Les Design PatternsIntroduction aux DPGoF : State, Singleton, Template MethodDe l’analyse à la conceptionApplication à l’étude de cas 6. Introduction aux « patterns »• Le succès d’une conception passe par l’attribution réussie des bonnes responsabilités aux bonnes classes• Problème : les décisions qui vont conduire à des systèmes extensibles et maintenables ne sont pas forcément évidentes• Solution : il y a des principes fondamentaux et éprouvés appelés « patterns » que tout concepteur expérimenté applique 7. Introduction aux « patterns »• Les « patterns » sont : • Des paires nommées (problème + solution) • Des conseils issus de la pratique d’experts• Une technique essentielle dans le monde de laconception orientée objet !• Les concepteurs aguerris conçoivent par le biais d’un « langage de patterns »• « Dans cette conception, j’ai associé les patternsState (État) et Singleton pour faciliter l’ajout denouveaux états… Vaudrait-il mieux que j’utilise leFlyweight ? » 8. Ressources sur les patterns• Exemples de patterns et de ressources : • Patterns GRASP• Neuf patterns d’attribution des responsabilités fondamentales• UML et les Design Patterns (Larman, 2001, CampusPress).• Les patterns « Gang of Four » (GoF)• 23 patterns courants dans des situations spécifiques• Le plus connu des ensembles de patterns orientés objets• Design Patterns (Gamma, et. al. 1995, AW).• Les patterns en Java• 50 patterns courants avec leur traduction en Java• Patterns in Java (Grand, 2003, Wiley).• … 9. Modèle de description (1/3)• Nom du pattern •Le nom du pattern véhicule succinctement l’essence du pattern •Il est essentiel de trouver un nom clair et facile à mémoriser !• Intention •Formule brève répondant aux questions suivantes :• Que fait le design pattern ?• Quels en sont le raisonnement et l’intention ?• Quel problème spécifique de conception traite-t-il ?• Également appelé •Autres noms connus du pattern, s’il en existe (alias)• Motivation •Scénario illustrant un problème de conception ainsi que la façondont les structures de classes et d’objets du pattern résolvent leproblèmesource : Design Patterns – Elements of Reusable Object-Oriented Software 10. Modèle de description (2/3)• Applicabilité • Quelles sont les situations dans lesquelles le design pattern peut être appliqué ? Quels sont les exemples de mauvaises conceptions que le pattern permet de traiter ?• Structure • Généralement, représentation graphique des classes du pattern créée à l’aide d’UML• Participants • Classes et/ou objets prenant part au design pattern avec leurs responsabilités respectives• Collaborations • Façon dont les participants collaborent afin d’assumer leurs responsabilités• Patterns connexes • Quels sont les design patterns liés de près à celui-ci ? Avec quels autres patterns celui-ci doit-il être utilisé ?source : Design Patterns – Elements of Reusable Object-Oriented Software 11. Modèle de description (3/3)• Conséquences •De quelle façon le pattern accomplit-il ses objectifs ? •Quels sont les compromis et les résultats liés à l’utilisation dupattern ?• Implémentation •Quels sont les pièges, les conseils ou les techniques dont il fautavoir connaissance lors de la mise en œuvre du pattern ? •Y a-t-il des questions spécifiques au langage ?• Exemple de code •Fragments de code illustrant la façon dont on pourrait mettre enœuvre le pattern avec un langage orienté objets• Usages connus •Exemples d’utilisation du pattern sur des systèmes réelssource : Design Patterns – Elements of Reusable Object-Oriented Software 12. Les Design Patterns GoFsource : Design Patterns – Elements of Reusable Object-Oriented Software 13. Le DP Singleton (1/2)• Problème : comment garantir la présence d’une seule instance d’une classe et fournir un point d’accès global à cette instance ?• Solution : sauvegarder l’objet singleton dans une variable statique et implémenter une méthode de classe retournant ce singleton• Notez que cela fournit un accès global sans les défautsdes variables globales• Le constructeur est déclaré privé (ou mieux : protégé) 14. Le DP Singleton (2/2) 15. Le DP Template Method (1/2)• Le pattern Template Method (TMP) est au cœur de la conception d’algorithmes génériques• Problème : comment concevoir des algorithmes variables et non variables ?• Solution : définissez le squelette d’un algorithme dans une méthode de super-classe, en confiant certaines étapes à des sous-classes 16. Le DP Template Method (2/2) 17. Le DP State (1/2) • Problème : le comportement d’un objet dépend de sonétat• l’objet doit changer de comportement à l’exécution• Il est nécessaire que la réponse d’une instance varie enfonction de son étatpublic void m1(){public void m1(){public void m2(){ public void m2(){public void m3(){public void m3(){if < test 1 >if < test 1 >if < test 1 > if < test 1 >if < test 1 >if < test 1 > methodA() methodA()methodC()methodC()methodE() methodE()else if < test 2 >else if < test 2 > else if < test 2 > else if < test 2 > else if < test 2 >else if < test 2 > methodB() methodB()methodD()methodD()methodF() methodF()}}} }}}• Solution : délégation + polymorphisme• Classe abstraite (ou interface) « Etat » 18. Le DP State (2/2) 19. Analyse de l’étude de casPrésentation Analyse des besoins Modèle du domaine 20. L’étude de cas (1/2)• Le jeu du Démineur … 21. L’étude de cas (2/2)• L’objectif de cette étude de cas est de concevoir un jeu de démineur comme celui qui est livré avec Windows©• Nous souhaitons utiliser un processus itératif et incrémental• La démarche classique de modélisation que nous allons appliquer est la suivante :• Analyse des besoins • Diagramme de cas d’utilisation • Diagramme de séquence système• Modèle du domaine • Diagramme de classes • Diagramme d’états• Modèle de conception objet • Diagramme de classes • Diagrammes d’interactions 22. Analyse des besoins (1/2)• Diagramme de cas d’utilisationParamétrer le jeu [Paramétrage]Jouer au démineurJoueur Extension points Itération 1 : avec paramétrage par défaut,Paramétrageet non prise en compte du marquage « ? »Help [Help]Consulter laide en ligne 23. Analyse des besoins (2/2)• Diagramme de séquence « système »DemineurJoueurinitialiser()decouvrirCase(Point)marquerCase(Point)etc. decouvrirCase(Point) gagné !! entrerNomHighScores(n) 24. Modèle du domaine (1/2)• Diagramme de classes du domaine 25. Modèle du domaine (2/2)• Diagramme d’états : la classe Case• Complexité itérative !Itération 1Itération ultérieure… 26. Application des Design Patterns avec Together© ConceptionDP StateDP Singleton DP Template Method 27. Architecture logique• Le modèle du domaine va nous servir de base pour la couche « domaine » de notre architecture logique en conception objet• Modèle simplifié en 3 couches 28. De l’analyse à la conception (1/3)• Dans le diagramme de classes, nous allons maintenant indiquer :• Les méthodes• La navigabilité des associations• Les dépendances entre classes• Les types des attributs et des méthodes (retour,paramètres)• Together permet d’ajouter facilement les constructeurs, accesseurs, etc. 29. De l’analyse à la conception (2/3)• Le modèle du domaine fournit des classes candidates pour le diagramme de classes de conception• Le concepteur peut être amené à fusionner certainsconcepts ou au contraire à introduire de nouvellesclasses de conceptionÉtat ?? 30. De l’analyse à la conception (3/3)• Diagramme de classes de conception• premier jet pour l’itération 1 31. Classes de conception• Ajout des types non-primitifs (optionnel) 32. Conception de la dynamique (1/3)• Pour chaque « opération système » complexe, nous allons réaliser un diagramme d’interaction (collaboration ou séquence) Démineur• La complexité se Joueur initialiser() trouve dans les deux opérations : decouvrirCase(Point) marquerCase(Point) • decouvrirCase(Point) etc.• marquerCase(Point)decouvrirCase(Point)gagné !!entrerNomHighScores(n) 33. Conception de la dynamique (2/3)• Commençons par « marquerCase » :• Le joueur clique sur un point du plateau, il faut déjà traiterl’événement graphique en trouvant la case concernée… 1: marquerCase(Point) :Partie1.1: marquerCase(Point)les:Case :Plateau 1.1.1: c:=get(Point) 1.1.2: marquer()1.1.2.1: ??c:Case 34. Conception de la dynamique (3/3)• Continuons « marquerCase » :• Si elle est toujours couverte, une case peut être marquée enrespectant les règles indiquées par le diagramme d’états• Le traitement à effectuer dépend donc entièrement de l’état de lacase pointée…• Nous allons utiliser le Design pattern du State• !Avantage : évolutivité facilitée (pour la prise en compte ultérieuredu marquage « ? ») 35. Application du DP State (1/4)• Diagramme de classes de conception « avant »• Ajout des méthodes dans Plateau et Case 36. Application du DP State (2/4) 37. Application du DP State (3/4)• Diagramme de classes de conception « après »« ! 38. Application du DP State (4/4)• Le code Java correspondant « après »« ! 39. Suite de la dynamique (1/2)• Continuons « marquerCase » :• En fonction de son état, la case effectue des traitements différentsmarquer(c : Case) :EtatDecouverte marquer(c : Case) 2: majCompteur(-1) :EtatCouverteNonMarquee:Partie 1: setEtatCourant(EtatDrapeau)c : Case marquer(c: Case)2: majCompteur(1) :EtatDrapeau:Partie 1: setEtatCourant(EtatCouverteNonMarquee)c : Case 40. Suite de la dynamique (1/2)• Quelles sont les améliorations du modèle que l’étudede la dynamique nous inspire ?• Les états doivent recevoir en paramètre la case elle-même pourpouvoir ensuite invoquer la méthode setEtatCourant() • marquer()marquer(c : Case) • Idem pour decouvrir(c : Case)• De nombreuses classes vont avoir besoin d’un accès à laclasse Partie : tous les états, etc.• Cette classe Partie doit avoir une seule instance à la fois ! • L’utilisation du DP Singleton est naturelle … 41. Suite de la dynamique (2/2)• Appliquons le DP Singleton à la classe Partie 42. Application du DP Singleton• Le modèle et le code Java correspondant « après »« ! 43. Classes de conception• Le modèle complété de l’itération 1 pourrait alors ressembler à: 44. Développement itératif• Le DP State facilite l’introduction itérative d’un nouvel état de marquage de la case Itération 1 Itération ultérieure… 45. Nouvelle application du State (1/2)• Together permet facilement d’ajouter un nouvel état concret• Grâce au paramètre “create pattern links” qui reconnaîtles participants au DP 46. Nouvelle application du State (2/2)• Diagramme de classes de conception « après »« ! 47. Conclusion 48. Pas de « pattern-alisme » excessif !• Une bonne conception n’implique pas d’utiliser tous les patterns de la terre !• Utilisez les bons patterns au bon endroit et justifiez votre solution !• Il est rare de réaliser une bonne conception dès la premièretentative• L’activité de refactoring aide à rectifier les erreurs• Développez de façon itérative• Évitez le syndrome du « silver bullet » !• Utilisation obsessionnelle d’un pattern ou d’une technologieauxquels vous êtes habitué• Méfiez-vous de ceux qui disent avoir un pattern préféré ! 49. Utilisez Together !Together permet d’appliquer plus facilement des patterns sur vos modèles UML … Il permet également de se créer ses proprespatterns ! Mais ceci est une autre histoire … 50. Questions? 51. Merci !N’oubliez pas de remplir le formulaire d’évaluation Vous pouvez me contacter à … [email protected]