Enseignant Chercheur ESIL/INFO France

Présentation au sujet: "Enseignant Chercheur ESIL/INFO France"— Transcription de la présentation:

1 Enseignant Chercheur ESIL/INFO France
Design Patterns Laurent Henocque Enseignant Chercheur ESIL/INFO France mis à jour en Octobre 2006

2 Licence Creative Commons
Cette création est mise à disposition selon le Contrat Paternité-Partage des Conditions Initiales à l'Identique 2.0 France disponible en ligne ou par courrier postal à Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

3 Préambule Ce support de cours présente de nombreux diagrammes, dont certains peuvent contenir des erreurs UML2 Il n'est donc pas utilisable sans l'aide d'un enseignant

4 Contexte De très nombreux projets logiciels font apparaître des éléments comparables Réinventer les meilleures solutions connues dans chaque nouveau projet est inutile, et risqué Analysis Patterns Design Patterns Frameworks Workflow Patterns

5 Pourquoi les Patterns La réussite prime sur la nouveauté
Importance de la clarté de la documentation Validation qualitative des acquis et de la connaissance pratique Importance de la dimension humaine dans le développement logiciel Faciliter la réutilisation de savoir faire

6 Sur la réutilisation Les langages informatiques modernes orientés objet permettent la réutilisation par importation de classes par héritage : extension / spécialisation par l'inversion de contrôle (aspects)

7 Schéma de conception réutilisable
Les patterns c'est quoi? Design Pattern = Schéma de conception réutilisable Organisation et hiérarchie de plusieurs modèles de classes réutilisable par simple implémentation, adaptation, extension

8 Comment? Les Design Patterns sont présentés en utilisant la notation graphique standard UML Pour l'essentiel, seule la partie statique (diagrammes de classes) de UML est utilisée

9 Diagrammes de Classes UML2 (éléments)
Classe_A relation Classe_B héritage Classe_C agrégat / composition Classe_D attributs fonctions dépendance

10 Références

11 Références Web http://patterndigest.com/
… google…

12 Exemples Simples : Intuition
Quelques exemples de "proto" patterns, ou d'éléments de conception réutilisables non officialisés

13 La Liste La liste (ce n'est pas un schéma, mais un élément de conception orientée objet) Ce modèle est largement criticable : quels sont ses défauts?

14 Collection Gestion de collections via une classe
Ce modèle ne respecte pas les conventions UML: quels sont ses défauts?

15 Attribut Relation Définir un rôle d'une relation (binaire) par un pointeur

16 Maître / Esclave Déléguer la gestion d'une relation à une classe intermédiaire

17 Objet Relation Modéliser une relation importante par un objet (on veut ignorer la façon dont la relation est gérée)

18 Les 23 Patterns

19 Types de Patterns Patterns structuraux Patterns de création
décrivent une organisation de classes dans l'optique "structure de données" Patterns de création décrivent des approches de création déléguée d'objets Patterns dynamiques décrivent une organisation de classes gérant les aspects dynamiques d'un système

20 Présentation de Schémas Simples
On débute par 7 schémas d'utilisation très répandue Composite Iterator Command Adapter Singleton Factory Method Template Method

21 Composite Composer des structures hiérarchiques

22 Composite : exemples Toute structure de données récursive
container graphique structure de document (chapitre/section/paragraphe...) container conceptuel (états composites dans UML)

23 Iterator Parcourir des conteneurs en masquant l'implantation

24 Iterator

25 Iterator : exemples Toute logique de parcours de container
Exemples nombreux en Java On veut enlever des structures de données toute information relative à son parcours, et ainsi permettre de faire varier les modes de parcours

26 Command Encapsuler une requête dans un objet

27 Command : exemples Command remplace les pointeurs vers fonctions dans tous les langages objet évolués. Command interface l'appel d'une opération via une méthode virtuelle. Utilisé dans les interfaces homme machine pour attacher un comportement à un objet

28 Function Object Encapsuler une fonction dans un objet (un autre nom pour "command") FunctionObject execute(param) ConcreteFunctionObject state

29 (Class) Adapter Convertir une interface par héritage multiple

30 Adapter : exemples Toute situation où l'on veut réutiliser du code, mais pas son interface de programmation. Par exemple, un code ancien, ou tiers, ne respecte pas notre charte de présentation

31 Object Adapter (Wrapper)
Convertir une interface par composition

32 Singleton Gérer une instance unique

33 Singleton : exemples Singleton permet de gérer la création à la demande (lazy) d'un objet unique. L'objet est créé au premier accès de façon invisible Exemples : le spooler d'impressions, le système de fichiers dans un OS

34 Factory Method Définir une interface de création, mais laisser les sous classes décider du type

35 Factory Method : exemples
C'est un fragment de Abstract Factory (voir plus loin) C'est un exemple de "Template Method" (voir ci après) Utile par exemple pour créer des itérateurs. Chaque classe d'une hiérarchie de containers implante sa version de "createIterator()", qui retourne un objet du type adéquat.

36 Template Method Prévoir un squelette de fonction, et compléter par les sous classes

37 Template method : exemple
La logique de création et archivage par nécessité suivante peut être définie par une super classe, et ses détails implantés par des sous classes Object get(String name){ Object o=find(name); if (o) return o; if (!canCreate(name)) return null; o = create(name); addToContainer(o); return o; }

38 Autres Schémas de Création
Présentation quasi alphabétique

39 Schémas de Création Abstract Factory : Builder : Factory Method :
interface de création de familles d'objets de type exact inconnu Builder : séparer création et représentation Factory Method : interface de création spécifiée par des sous classes Prototype création par clonage Singleton classe à instance unique

40 Abstract Factory Interface de création de familles de produits

41 Abstract Factory : exemples
Permet de changer le look and feel d'une interface en changeant le type des objets créés en changeant simplement d'object factory Peut aussi servir pour changer globalement les types de containers utilisés par un programme (listes ou tableaux ou hashtables) par exemple

42 Builder Séparer la construction d'un objet complexe de sa représentation

43 Builder : exemples L'exemple type est celui d'un convertisseur "à la volée" de texte formaté. vers un autre format vers des formats avec perte (html -> texte seul) Le principe est qu'à chaque rencontre d'une unité remarquable (balise, chaîne de caractères, texte libre...) le parseur invoque le convertisseur. En changeant ce dernier, on change le format de sortie.

44 Prototype Créer des instances par clonage de prototypes

45 Prototype : exemples C'est la base de la mise en œuvre du copier/coller dans les interfaces graphiques

46 Autres Schémas Structuraux
Présentation alphabétique

47 Schémas Structuraux Adapter Bridge Composite Decorator Façade
convertir une interface en une autre pour réutilisation Bridge découpler une abstraction de son implantation Composite structures arborescentes Decorator attachement dynamique de fonctionnalités Façade interface unique sur les interfaces d'un module Flyweight objets ultra légers Proxy représentant local d'un objet distant

48 Bridge Découpler une abstraction de son implantation

49 Bridge : exemples On se trouve dans le cas où l'on doit maintenir en même temps une hiérarchie d'abstractions et plusieurs hiérarchies d'implantation différentes : par exemple pour réaliser des interfaces graphiques portables On peut aussi vouloir cacher des interfaces de programmation (C++) : cas particulier type de la classe "Handle"

50 Decorator Attacher des responsabilités dynamiquement

51 Decorator : exemples On veut attacher dynamiquement des traitements effectués de manière récursive Exemple : dans les interfaces graphiques, l'affichage des "décorations" : barre de saisie, ascenseurs, transparence etc... Autre possibilité : pour la sérialisation : ajout de balises html/xml autour du source généré par exemple.

52 Façade Interfacer un sous système par une classe façade

53 Facade : exemples Votre compilateur C++ en ligne de commande favori : permet l'invocation d'une session complète, ou du préprocesseur seul, ou du linker...

54 Flyweight Gérer des millions de pseudo objets associés à des données de base

55 Flyweight exemples Dans un éditeur de textes, faire de chaque caractère un objet. Dans un afficheur de signaux radars, faire de chaque signal un objet.

56 Proxy Définir un représentant local d'un objet accessible à distance

57 Proxy : exemples interface des EJB

58 Autres schémas dynamiques
Présentation alphabétique

59 Schémas Dynamiques Chain of Responsibility Command Interpreter
découpler l'objet responsable d'un traitement Command objet fonction Interpreter représentation de la sémantique d'une grammaire Iterator accès séquentiel au contenu d'un container Mediator modélisation de l'interaction d'objets Memento support du undo

60 Schémas Dynamiques Observer State Strategy Template Method Visitor
gestion des notifications State définir les états par des classes Strategy définir des familles d'algorithmes interchangeables Template Method définir le squelette d'un algorithme Visitor permettre d'appliquer une opération aux éléments d'une structure de données

61 Chain of Responsibility
Eviter de coupler le demandeur d'une requête et son récepteur

62 exemples le système de prise en compte des événements dans le logiciel hypercard toute ihm ou l'on voudrait que par défaut un click s'il n'est pas traité par un bouton soit traité par un script d'un conteneur englobant, à un niveau quelconque

63 Interpreter Explorer un arbre syntaxique

64 Interpreter : exemples
Utile pour la version "luxe" de "Builder". On a fait une analyse syntaxique, et on veut exploiter la structure de données hiérarchique qui a été construite pour: compiler traduire ...

65 Mediator Alléger le coût d'une communication nxn par un médiateur

66 Mediator

67 Mediator : exemples Dans une interface graphique, gérer des dépendances complexes entre des composants de saisie/visualisation

68 Memento Prévoir la restauration de l'état d'un objet (Undo)

69 Observer Définir une relation entre objets pour que chaque mise à jour soit notifiée

70 Observer : exemples Toujours dans une interface graphique par exemple, permettre la notification entre des vues multiples éditables ou non d'une même donnée. Par exemple feuille de calcul/diagrammes

71 State Gérer les états par une hiérarchie de classes

72 State : exemples La fonction "display" d'une icône représentant une connexion change selon l'état. Pour le code qui invoque display, il suffit de changer dynamiquement l'objet qui implémente l'état pour que cette particularité soit insensible

73 Strategy Varier dynamiquement les algorithmes

74 Strategy : exemples les tris ont des plages d'optimalité.
On peut changer une foi pour toutes l'algo de tri attaché à un (itérateur de) vecteur par exemple, dès que le nombre de constituants dépasse 5

75 Explorer une structure de données hiérarchique
Visitor

76 Visitor : exemples permettre l'appel d'une fonction sur des éléments d'une structure de données sans avoir à réécrire l'algo de parcours à chaque fois. la fonction "map" de LISP

77 Autres Patterns Utiles

78 Inversion de dépendance
L'inversion de dépendance permet de rendre un code indépendant de ses conditions d'initialisation , et des API précises des ses données d'initialisation Utile dans les architectures multi couches Exemple: le framework Spring: le projet Pico ( le projet Avalon

79 Inversion de Dépendance par les setters

80 Inversion de Dépendance par les constructeurs

81 Patterns Aggrégés

82 Model View Controller

83 Model View Controller MVC peut être vu comme une combinaison de design patterns Les vues sont organisées selon Composite Le lien entre vues et modèles est l' Observer. Les contrôleurs sont des Strategy attachées aux vues. MVC peut mettre en jeu encore d'autres patterns: Le modèle est souvent un Mediator Les arbres de vues mettent en œuvre Decorator On a souvent besoin d' Adapter pour convertir l'interface d'un Modèle de façon à ce qu'elle soit adaptée aux vues. Les vues créent les contrôleurs avec FactoryMethod.

84 Document View Pattern Document View est une version simplifiée de MVC où la vue agit selon le pattern Observer, et est mise à jour en fonction de l'état du document (Mis en œuvre dans les MFC)

85 General Responsibility Assignment Software Patterns or Principles
GRASP General Responsibility Assignment Software Patterns or Principles

86 GRASP GRASP propose des guides généraux d'organisation des interfaces de programmation orientée par le concept de "responsabilité" attachée aux classes. Les "patterns" GRASP fournissent une canevas logique pour déployer des interfaces garantissant un niveau amélioré de réutilisabilité

87 Information Expert Ce modèle représente le plus fondamental des allocations de responsabilité: La responsabilité doit être attachée à la classe la plus compétente (Information Expert)

88 Creator La classe responsable de créer de nouvelles instances d'une classe C est celle qui: agrège, contient, enregistre les instances de C utilise les instances de C possède l'information nécessaire pour créer les C

89 Controller La responsabilité de traiter les événements système est déléguée à une classe non membre de l'interface utilisateur qui représente le système entier ou un scénario de cas d'utilisation Un contrôleur de use case doit être capable de gérer la totalité des évènements possibles d'un cas d'utilisation. Un contrôleur peut gérer les évènements de plusieurs scénarios si nécessaire

90 Low Coupling Le "couplage faible" renvoie aux aspects de l'organisation logicielle qui permettent: de limiter les dépendances entre classes de réduire l'impact du changement sur les autres classes d'augmenter la réutilisabilité Les stratégies qui le permettent sont variées, mais reposent largement sur l'inversion de contrôle et les design patterns de séparation (bridge, builder, decorator, mediator etc...)

91 High Cohesion La "cohésion forte" est une stratégie d'organisation des classes qui vise à associer au sein d'une même classe des services fortement voisins ou reliés

92 Polymorphisme Quand des variations de fonctionnalités sont induites par le type des objets, la responsabilité de ces variations est données à des sous classes qui implantent le type, à une opération surchargée dans chaque cas par la méthode appropriée

93 Pure Fabrication Une "Pure Fabrication" est une classe ne faisant pas partie des objets métier ou technique, mais introduite pour les seuls besoins de satisfaire "low coupling et/ou high cohesion" ou tout autre besoin dicté par les GRASP

94 Indirection Utiliser un intermédiaire (pattern Mediator par exemple) pour satisfaire les impératifs de couplage faible

95 Protected Variations Protéger un ensemble logiciel des variations d'un élément en groupant ses parties instables dans une interface, dont les implantations réalisent les variations

96 Trois principes liés aux design et grasp patterns

97 Single-Responsibility Principle
Une classe doit n'avoir qu'une seule raison de changer. Ce principe est une lecture du principe de "cohésion forte". La classe ne doit offrir que des services fortement reliés on ne combine pas rémanence et fonctionnalité par exemple Ce principe contredit de facto l'usage de l'héritage pour extension

98 Interface-Segregation Principle
Un programme ne doit pas dépendre de méthodes qu'il n'utilise pas Principe également lié à la cohésion forte Conduit à la multiplication d'interfaces très spécifiques et petites.

99 Open-Closed Principle
Un code doit être "ouvert à l'extension, mais fermé à la modification". En d'autres termes, tout ajout de fonctionnalité ou évolution du logiciel doit se faire de façon incrémentale, sans modifier une ligne de source existante Une approche de ce principe se fait par les design patterns "template method" et "strategy

100 Design Patterns J2EE

101 Les Patterns J2EE Java a popularisé une liste de Patterns utilisés dans la mise en œuvre d'applications à base d'EJB Chaque Pattern n'est pas une collaboration au sens propre, mais le nom d'une classe, dotée de fonctionnalités particulières, et qui entre dans des interactions spécifiques avec d'autres

102 http://java.sun.com/blueprints/ corej2eepatterns/Patterns/index.html

103 http://java.sun.com/blueprints/ corej2eepatterns/Patterns/index.html

104 http://java.sun.com/blueprints/ patterns/catalog.html
Business Delegate Reduce coupling between Web and Enterprise JavaBeansTM tiers Composite Entity Model a network of related business entities Composite View Separately manage layout and content of multiple composed views Data Access Object (DAO) Abstract and encapsulate data access mechanisms Fast Lane Reader Improve read performance of tabular data Front Controller Centralize application request processing Intercepting Filter Pre- and post-process application requests Model-View-Controller Decouple data, behavior, and presentation Service Locator Simplify client access to enterprise business services Session Facade Coordinate operations between multiple business objects in a workflow Transfer Object Transfer business data between tiers Value List Handler Efficiently iterate a virtual list View Helper Simplify access to model state and data access logic

105 Références Mastering EJB 3.0 EJB Design Patterns
EJB Design Patterns L'ensemble du site est utile:

106 Conclusion Les patterns fournissent un outil puissant
de documentation de savoir-faire de nommage de concepts universellement utilisés de réutilisation pratique de modèles objet dans les projets

107 Autres Pseudo Patterns référencés

108 Casting Method Prédéfinir les casts

109 Connected Group Gérer collectivement les connexions

110 Double Checked Locking
class Singleton { public: static Singleton * instance(); private: static Singleton * self; static SEMAPHORE key; } Singleton * Singleton::instance() { if (self == 0) { if ( lock(key) >= 0 ) { if (self == 0 ); //double-check! self = new Singleton; unlock (key); } } }

111 Flexible Service Faire d'une fonction une classe, évaluée de manière retardée

112 Eviter les down casts Intelligent Children

113 Is Kind Of Fournir des informations de type

114 Multiton class User { public:
static const User * LogIn(const char * name, const char * password); protected: virtual User * Lookup(const char *name); private: List<UserName> * _instances; } class UserName : public ListItem { User* instance; char* name;

115 Mutual Friends Représenter une relation bidirectionnelle

116 Named Object

117 Null Object Représenter une relation partielle

118 Objectifier Permettre à un objet de faire varier dynamiquement son comportement

119 RTTIVisitor Obtenir un cast sûr au moyen du pattern visitor

120 Sender Argument Permettre de s'identifier auprès d'autres objets par passage d'une référence

121 Serializer Ecrire les objets dans des flux de données pour les reconstruire plus tard

122 Timed Relationship Représenter une relation qui varie au cours du temps