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

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

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

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 ...

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 !

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

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

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

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

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…

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

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

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

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

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

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

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

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

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

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

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

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

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 !

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

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

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

Conclusion 1 rôle => 1 interface + délégation à 1 objet 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 !

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

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

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)...

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

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)

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 ».

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

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

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

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

Exemple

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

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

« 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 !

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)

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