Design Patterns Cours IUT 7 mars 2001 Arnaud Nauwynck & Nédra Mellouli

Présentation au sujet: "Design Patterns Cours IUT 7 mars 2001 Arnaud Nauwynck & Nédra Mellouli"— Transcription de la présentation:

1 Design Patterns Cours IUT 7 mars 2001 Arnaud Nauwynck & Nédra Mellouli arnaud.nauwynck@socgen.com

2 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 3 Plan  Orienté-Objet & Design Patterns  Généralités sur les Design Patterns  Étude de Cas  Utilisation & méthode d’apprentissage Conclusion

4 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 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 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 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 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 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 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 : 1. Structure interne / Dessins des formes 2. Changements synchronisés 3. Groupes d’objets (Group / Ungroup) 4. Comportements de la souris, des menus contextuels 5. Conversions en multiples formats…

11 11 Pb 1/5 : MVC  Fichiers / Représentations Internes / Vues / Interactions utilisateurs VectorielPixel ContrôleurVue Séparation Modèle-Vue!!! Forme CercleSegment Dessin Séparation Vue-Contrôleur Séparation Modèle-Contrôleur Modèle - Vue -Contrôleur

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

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

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

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

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

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

18 18 Pb 3/5 : Composite..  Group / Ungroup Forme CerclesSegments FormeComposite 0..* Sous-formes

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

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

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

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 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)  Chaîne de responsabilité  Commande  Interpréteur  Itérateur  Médiateur  Mémento  Observateur  État  Stratégie  Patron de méthode  Visiteur

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