Design Patterns

1. Design Patterns Arnaud Nauwynck1 & Nédra Mellouli2 arnaud.nauwynck@socgen.com 1Société Softeam Paris 2IUT de Montreuil UNIV-Paris8

2. Introduction • Thèse de Erich Gamma • Edité en un livre • Auteurs: E. Gamma, R. Helm, R. Johnson, J. Vlissides • Livre devenu best-seller informatique • Vision nouvelle(?) et incontournable

3. Plan • Orienté-Objet & Design Patterns • Généralités sur les Design Patterns • Étude de Cas • Utilisation & méthode d’apprentissage Conclusion

4. Mots - clefs • Titre : Design Patterns • Catalogue de Modèles de conception réutilisables • Elements of Reusable Object-Oriented Software • Mots-clefs = architecture, organisation, rôles, simple, intelligible, éprouvé, flexible, concepts OO, modulaire, (ré)utilisable ...

5. Objectifs / Positionnement • Pré requis • connaissance Orientée-Objet • Langage OO : C++ / Java.. • Concepts de Librairies • Buts • Concepts abstraits • Vocabulaire des concepts (complémentaire d’UML) • Nouvelle vision du monde du logiciel • Non – Buts • Pas liés à un langage précis • Pas un livre d’apprentissage, pas de recettes !

6. L’Héritage en Orienté-Objets • 3 Façons de réutiliser les Objets • Héritages (d’interface / de code) • Composition • Templates (généricité de types..) • Héritage de code : souvent utilisé à tords • L’héritage d’interface : Light Motifs des Design Patterns

7. Limitation d’une approche naïve de l’Orienté-Objets • Recensement « Merisien » des objets • Données, pas Interfaces ! • Objets fonctionnels seulement, Pas informatiques! • Héritage de code • forte corrélation classes / sous-classes.. • Traitements mélangés entre classes • Grande difficulté de compréhension • insuffisance des diagrammes de classes de UML

8. Buts : Rôles des objets • Limitation des dépendances / connaissances entre objets • Introduction de dépendances dynamiques tardives (« late binding ») • Par opposition : suppression des dépendances à la compilation.. • Rôles des objets systématiquement épurés, et définis par des interfaces 1 rôle => 1 interface + délégation à 1 objet Possibilité de changement ouverte

9. 23 Patterns / 3 classifications Des objets où, comment, pourquoi faire ?.. • Identification et rôles des objets et des relations • 1) Modèles Créateurs • Créer un objet / Accéder à un objet • 2) Modèles Structuraux • Combiner les objets en structures • 3) Modèles de Comportement • Utiliser les objets pour implanter des fonctionnalités

10. Etude de cas : 5 Problèmes Concevoir l’architecture (classes en UML) d’un logiciel de dessin géométrique supportant les cercles, segments, groupes… Parties à clarifier : • Structure interne / Dessins des formes • Changements synchronisés • Groupes d’objets (Group / Ungroup) • Comportements de la souris, des menus contextuels • Conversions en multiples formats…

11. Séparation Vue-Contrôleur Séparation Modèle-Contrôleur Contrôleur Vue Dessin Forme Vectoriel Pixel Cercle Segment Séparation Modèle-Vue!!! Pb 1/5 : MVC Vue - Contrôleur Modèle - • Fichiers / Représentations Internes / Vues / Interactions utilisateurs

12. Dessin Vues Forme Vectoriel Pixel Cercle Segment Pb1/5 : MVC (Suite) : Contrôleur Traitements / GUI Contrôleur Traitements / GUI Notification, affichage Séparation Modèle-Vue!!!

13. Dessin Vues Forme Vectoriel Pixel Cercle Segment Pb1/5 : MVC (Suite) Architecture 2 tiers Contrôleur Traitements Contrôleur GUI Requêtes actions évènements GUI Notification, affichage Séparation Modèle-Vue!!! Serveur Applicatif (serveur d’objets) Client Graphique (client léger)

14. Dessin Vues Forme Vectoriel Pixel Cercle Segment Pb1/5 : MVC (Suite) Architecture 3 tiers Contrôleur DB Contrôleur Traitements Contrôleur GUI Requêtes Requêtes Persistence Sql, Xql.. Notification, affichage Serveur de Base de Données Serveur Applicatif Client Graphique (client léger)

15. Pb2/5 : Publish & Subscribe • Notifications de changement 0..* listVues Vue SetSrcObject(o) Notify(chgEvent) Sujet Subscribe / addVueListener(v) Resign / removeVueListener(v) FireAll(chgEvent) { for_list(vue,v) v->Notify(chgEvent) } 0..1 srcObject

16. Pb 2/5: Publish & Subscribe (Bis) • Indépendance des Vues pour l’Objet 0..* listVues VueAbstraite SetSrcObject(o) <<Abstract >>Notify(chgEvent) Forme addVueListener(v) removeVueListener(v) FireAll(chgEvent) 0..1 srcObject Vue1 Notify() { .. Draw1 } Vue2 Notify() { .. Draw2 }

17. Pb2/5: Publish & Subscribe (Ter) Indépendance des Objets pour les Vues (cf. MVC) 0..* listVues SujetAbstrait addVueListener(v) removeVueListener(v) FireAll(chgEvent) <<abstract>>getXX() <<abstract>> getRenderer() VueAbstraite SetSrcObject(o) Notify(chgEvent) 0..1 srcObject Vue1 Vue2 Sujet1 getXX getRenderer Sujet2 getXX getRenderer

18. 0..* Forme Sous-formes FormeComposite Cercles Segments Pb 3/5 : Composite.. • Group / Ungroup

19. 0..1 forme sous-jacente Forme 0..* Sous-formes Proxy Cercles Segments Composite Pb3/5 : Composite, Proxy.. • Formes par procuration (Rotation, Iconifiée, En cours de chargement, etc..)

20. Pb4/5 : Délégation, Chaîne de Responsabilité.. • Gestion de la souris, des évènements graphiques… GestionApplication Application Vue GestionVue GestionForme Formes GestionSegment Cercles Segments Menu Contextuel

21. TraitementTypeFactory getTypeTraitement(name) TypeTraitement ..Factory.getSingleton() TypeConvertisseurPs createInstance TypeConvertisseurBmp Traitement Formes ConvertisseurPs ConvertisseurBmp Cercles Segments Pb 5/5 : Stratégie, Visiteur, Factory, Singleton… • Conversions Multiples, etc..

22. Retour sur les 23 Patterns Les 23 Patterns se trouvent partout Sous formes réduites, déguisées, renommées… Lire des programmes … Savoir les reconnaître et comprendre l’architecture Ecrire : savoir en mettre partout (!!), en respectant les concepts

23. Description des 23 Patterns ? / Réflexion de chacun !! • Découverte • Bon sens, mais c’est bien sûr.. • 1ère Lecture • Catalogue Universitaire ? • 1ère pratique • Je connais!.. Je vais réessayer pareil… • Oups.. Je dois relire quelques détails.. • 2ème lecture • C’est très fort • 2ème pratique • On les vois partout ! On en met partout !

24. Liste des Patterns : Modèles créateurs (1/3) Fabrique Abstraite (Abstract Factory, Kit) Monteur (Builder) Fabrication (Factory method) Prototype Singleton

25. Liste des Patterns : Modèles Structuraux (2/3) Adaptateur Pont Composite Décorateur Façade Poids Mouche Procuration (Proxy)

26. Liste des Patterns : Modèles Comportementaux (3/3) • Observateur • État • Stratégie • Patron de méthode • Visiteur Chaîne de responsabilité Commande Interpréteur Itérateur Médiateur Mémento

27. Conclusion Un livre à lire 2 fois 1 rôle => 1 interface + délégation à 1 objet Possibilité de changement ouverte La programmation devient tellement plus simple !

28. Cadre pédagogique à l'IUT de Montreuil : design patterns par la théorie et la pratique Nelly Ben simon Nédra Mellouli Serge Rosmoduc n.bensimon@iut.univ-paris8.fr

29. Nos choix • En algorithmique et programmation • forte orientation OO • java dès la première année • enseignement GI à forte coloration java : jdbc/jsp/servlets

30. Patterns et java • Intérêt architectural des patterns : mieux structurer le code • intérêt pour la pédagogie OO : systèmes non triviaux de classes qui collaborent • Nécessaires pour comprendre les bibliothèques java : les patterns y sont omniprésents swing (Observateur...), jdbc (Abstract Factory)...

31. L'enseignement des patterns • problème : les patterns répondent à des questions que les étudiants ne se posent pas • la présentation classique des patterns suppose une expérience de la programmation • donner cette expérience par des projets ? long. • présentation multiples des patterns • En programmation réseau • En imagerie numérique (essentiellement le visiteur) • En OMGL dans le cadre d'un projet transversal en option GI, depuis cette année

32. Les patterns à Montreuil • trois cours • Une conférence suivie d'une séance de TP réalisées par un intervenant de la société Softeam • un mini-projet • mise en évidence systématique des patterns rencontrés en programmation • projet transversal (OMGL/EOG/PROG)

33. Cours • principes de conception OO ; • introduction aux design patterns : observateur (MVC, architectures 2/3-3/3) ; • design patterns : commande, visiteur • Mini-projet « Statistiques :Histogramme, Camenbert et texte ».

34. Mini-projet « Statistiques » • une première partie donnée avant la présentation du MVC • une seconde partie donnée après.

35. Première partie : solution proposée par un binôme

36. Deuxième partie : solution proposée par le même binôme

37. Les patterns dans les TPs de programmation • proposer une architecture correcte des programmes développés en TP • problème : cela prend du temps (2h de TP par semaine ?!?) • solution utilisée : fournir une base déjà développée (voir transparent suivant) • demander aux étudiants de la documenter (UML) • rester simple

38. Exemple

39. Mandel (exercice sur les threads) • on fournit un programme graphique fonctionnel • sa structure est déjà bonne (pas de refactoring nécessaire) • on demande de l'améliorer

40. TP JDBC : Annuaire • architecture déjà fournie • couches interface/logique métier/modèle/persistance • exercice sur les différentes couches • implémenter des parties de la couche persistance • ajouter des fonctionnalités • passer d'une interface texte à une interface graphique, puis jsp

41. « Cas transversal » • Mener un grand projet : sur un cas réel • Analyse des besoins du client • Organisation de chaque groupe d'étudiant et planning • Proposition d'un modèle en UML : utilisatios de certains patterns pour mieux découper : Strategie, proxy, fabrique abstraite, singleton… • Validation avec l'accord du client • Découpage en différentes tâches • Développement de chaque tâche • Integration : c'est une phase pénible pour les étudiants • Ils s'apperçoivent de leurs erreux et de leurs mauvais choix! • C'est une phase de reflexion et d'autocorrection !

42. Les projets tuteurés • Les étudiants sont fortement incités par certains tuteurs à mettre les patterns en application • programmes d'exemples fournis • « dessin géométrique » et « éditeur de MCT/MOT » • mise en oeuvre du pattern MVC ; • architecture non triviale du modèle ; • patterns commande, visiteur... • (Voir exécutable)

43. Conclusion sur les projets • Enseigment • Cours : très peu • Plus de tranversalité • TPs : application des patterns progressivement • Impossible de maîtriser tous les patterns demandé (observateur, commande, visiteur) • Plus de consentration sur l'observateur • Cas tranversal • Occasion précieuse pour assimiler les design patterns • Sacrifier du temps et de l'énergie : nombre d'intervenants, l'encadrement, temps d'encadrement