Design Patterns

Arnaud Nauwynck1 & Nédra Mellouli2

arnaud.nauwynck@socgen.com1Société Softeam Paris

2IUT de Montreuil UNIV-Paris8

2

IntroductionThèse de Erich GammaEdité en un livreAuteurs: E. Gamma, R. Helm, R.

Johnson, J. VlissidesLivre devenu best-seller informatiqueVision nouvelle(?) et incontournable

3

Plan

Orienté-Objet & Design PatternsGénéralités sur les Design PatternsÉtude de CasUtilisation & 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é à tordsL’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 interfaces1 rôle => 1 interface + délégation à 1 objetPossibilité 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éateursCréer un objet / Accéder à un objet

2) Modèles StructurauxCombiner les objets en structures

3) Modèles de ComportementUtiliser les objets pour implanter des fonctionnalités

10

Etude de cas : 5 ProblèmesConcevoir 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és3. Groupes d’objets (Group / Ungroup)4. Comportements de la souris, des menus contextuels5. Conversions en multiples formats…

11

Pb 1/5 : MVC

Fichiers / Représentations Internes / Vues / Interactions utilisateurs

Vectoriel Pixel

Contrôleur

Vue

SéparationModèle-Vue!!!

Forme

Cercle Segment

Dessin

SéparationVue-Contrôleur

SéparationModèle-Contrôleur

Modèle - Vue - Contrôleur

12

Pb1/5 : MVC (Suite) : Contrôleur Traitements / GUI

Vues

Vectoriel Pixel

SéparationModèle-Vue!!!

Notification, affichage

Forme

Cercle Segment

Dessin

ContrôleurTraitements / GUI

13

Pb1/5 : MVC (Suite) Architecture 2 tiers

Vues

Vectoriel Pixel

ContrôleurGUI

SéparationModèle-Vue!!!

ContrôleurTraitements

Serveur Applicatif(serveur d’objets)

Client Graphique (client léger)

Notification, affichage

Requêtes

Forme

Cercle Segment

Dessin

évènements GUIactions

14

Pb1/5 : MVC (Suite) Architecture 3 tiers

Vues

Vectoriel Pixel

ContrôleurGUI

ContrôleurTraitements

Serveur Applicatif Client Graphique (client léger)

Notification, affichage

Requêtes

Forme

Cercle Segment

Dessin

RequêtesPersistence

Serveur de Base de Données

Sql, Xql..

ContrôleurDB

15

Pb2/5 : Publish & Subscribe

Notifications de changement

SujetSubscribe / addVueListener(v)Resign / removeVueListener(v)FireAll(chgEvent) { for_list(vue,v) v->Notify(chgEvent) }

VueSetSrcObject(o)Notify(chgEvent)

0..* listVues

0..1 srcObject

16

Pb 2/5: Publish & Subscribe (Bis)

Indépendance des Vues pour l’Objet

FormeaddVueListener(v)removeVueListener(v)FireAll(chgEvent)

VueAbstraiteSetSrcObject(o)<<Abstract >> Notify(chgEvent)

0..* listVues

0..1 srcObject

Vue1Notify() {.. Draw1}

Vue2Notify() {.. Draw2}

17

Pb2/5: Publish & Subscribe (Ter)Indépendance des Objets pour les Vues

(cf. MVC)

SujetAbstraitaddVueListener(v)removeVueListener(v)FireAll(chgEvent)<<abstract>> getXX()<<abstract>> getRenderer()

VueAbstraiteSetSrcObject(o)Notify(chgEvent)

0..* listVues

0..1 srcObject

Vue1 Vue2Sujet1getXXgetRenderer

Sujet2getXXgetRenderer

18

Pb 3/5 : Composite..Group / Ungroup

Forme

Cercles Segments FormeComposite

0..*Sous-formes

19

Pb3/5 : Composite, Proxy.. Formes par procuration (Rotation, Iconifiée, En cours de chargement, etc..)

Forme

Cercles Segments Composite

0..* Sous-formes

Proxy

0..1 forme sous-jacente

20

Pb4/5 : Délégation, Chaîne de Responsabilité..

Gestion de la souris, des évènements graphiques…

Formes

Cercles Segments

Vue

Application

GestionSegment

Menu Contextuel

GestionForme

GestionVue

GestionApplication

21

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

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 !

Liste des Patterns : Modèles créateurs (1/3)

Fabrique Abstraite (Abstract Factory, Kit)Monteur (Builder)Fabrication (Factory method)PrototypeSingleton

Liste des Patterns : Modèles Structuraux (2/3)

AdaptateurPontCompositeDécorateurFaçadePoids MoucheProcuration (Proxy)

Liste des Patterns : Modèles Comportementaux (3/3)

Chaîne de responsabilitéCommandeInterpréteurItérateurMédiateurMémento

ObservateurÉtatStratégiePatron de méthodeVisiteur

Conclusion

1 rôle => 1 interface + délégation à 1 objetPossibilité de changement ouverte

La programmation devient tellement plus simple !

Un livre à lire 2 fois

Cadre pédagogique à l'IUT de Montreuil : design

patterns par la théorie et la pratique

Nelly Ben simon Nédra Mellouli

Serge Rosmoducn.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 coursUne conférence suivie d'une séance de

TP réalisées par un intervenant de la société Softeam

un mini-projetmise en évidence systématique des

patterns rencontrés en programmationprojet transversal (OMGL/EOG/PROG)

33

Cours

principes de conception OO ; introduction aux design patterns :

observateur (MVC, architectures 2/3-3/3) ;

design patterns : commande, visiteurMini-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

fonctionnelsa 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