Design Patterns

1
Design Patterns

• Laurent Henocque
• http//laurent.henocque.free.fr/
• Enseignant Chercheur ESIL/INFO France
• http//laurent.henocque.perso.esil.univmed.fr/
• mis à jour en Septembre 2008

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
• http//creativecommons.org/licenses/by-sa/2.0/fr/
  
• 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
Objectifs pédagogiques

• Permettre, en découvrant les design patterns, de
  maîtriser totalement les diagrammes de classes
• Prérequis pour létude des spécifications UML
• Cest un cours dapprentissage de lagilité à
  comprendre et formuler des modèles abstraits

5
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

6
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

7
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
• par les aspects

8
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

9
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

10
Diagrammes de Classes UML2 (éléments)
Classe_A
Classe_B
relation
héritage
Classe_C
Classe_D
agrégat / composition
attributs
fonctions
dépendance
11
Références
12
Références Web

• http//patterndigest.com/
• http//norvig.com/design-patterns
• http//www.industriallogic.com/papers/index.html
• google

13
Exemples Simples Intuition

• Quelques exemples de "proto" patterns, ou
  d'éléments de conception réutilisables non
  officialisés

14
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?
15
Collection

• Gestion de collections via une classe

Ce modèle ne respecte pas les conventions UML
quels sont ses défauts?
16
Attribut Relation

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

17
Maître / Esclave

• Déléguer la gestion d'une relation à une classe
  intermédiaire

18
Objet Relation

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

19
Les 23 Patterns
20
Types de Patterns

• Patterns structuraux
• 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

21
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

22
Composite

• Composer des structures hiérarchiques

23
Analyse

• Composite superpose une hiérarchie de types
  (taxonomie) et une hiérarchie de conteneurs
  (partonomie).

24
Composite exemples

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

25
Exercices

• Définir une hiérarchie de classes récursive pour
  des interfaces homme machine (trois classes
  suffisent)
• Définir un modèle pour des expressions
  arithmétiques

26
Iterator

• Parcourir des conteneurs en masquant
  l'implantation

27
Iterator
28
Analyse

• Itérator sépare la logique de litération dans un
  objet indépendant dont les états logiques et
  physiques correspondent.
• Sert de nombreux impératifs de bonne conception
  (séparation, masquage, couplage faible)
• Permet de définir des hiérarchies ditérateurs

29
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

30
Exercices

• Lister les différents services attendus des
  itérateurs
• Définir un modèle compatible avec itérator pour
  deux classes liste et vecteur et deux itérateurs
  pour chacune delles

31
Command

• Encapsuler une requête dans un objet

32
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

33
Exercices

• Imaginer une api pour mettre en place des
  callbacks dans une interface au moyen de
   command 
• Imaginer un mécanisme basé sur command permettant
  dappeler une chaîne dopérations automatiquement

34
Function Object

• Encapsuler une fonction dans un objet (un autre
  nom pour "command")

35
(Class) Adapter

• Convertir une interface par héritage multiple

36
Adapter exemples

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

37
Object Adapter (Wrapper)

• Convertir une interface par composition

38
Exercice

• Définir trois classes de formes géométriques
  indépendantes, et nappartenant pas à une
  hiérarchie, puis définir une hiérarchie qui
  réutilise les précédentes par adaptation

39
Singleton

• Gérer une instance unique

40
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

41
Exercice

• Définir une classe singleton en Java, avec
  initialisation paresseuse (on ne crée lunique
  instance quau moment du premier accès)
• Id, mais avec une initialisation à priori

42
Factory Method

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

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

44
Exercice

• Mettre en uvre  factory method  dans le cas
  ditérateurs

45
Template Method

• Prévoir un squelette de fonction, et compléter
  par les sous classes

46
Analyse

• Il sagit dune sorte dhéritage inversé
• Les sous classes héritent dun algorithme
  générique, dont elles implantent les éléments
  spécifiques

47
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 ofind(name)
• if (o) return o
• if (!canCreate(name)) return null
• o create(name)
• addToContainer(o)
• return o

48
Exercice

• Définir un exemple de template method
• (une boucle  for avec deux appels de fonctions
  spécifiques)
• Template method requiert de définir une classe
  pour chaque mise en uvre. Peut on adapter l
  exemple précédent de sorte quil utilise function
  object à la place?

49
Autres Schémas de Création

• Présentation quasi alphabétique

50
Schémas de Création

• Abstract Factory
• 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

51
Abstract Factory

• Interface de création de familles de produits

52
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

53
Exercices

• Définir une api permettant de changer de type de
  collection (basé sur les listes simples ou les
  tableaux ou les tableaux associatifs) simplement
  en changeant de container factory.
• La collection doit seulement implanter laccès
  aléatoire (valeur à une position  i )

54
Builder

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

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

56
Analyse

• Selon le schéma  Builder , le  director 
  garde la maîtrise des appels au  builder .
• La situation serait différente si la structure de
  données était parcourue automatiquement

57
Prototype

• Créer des instances par clonage de prototypes

58
Prototype exemples

• C'est la base de la mise en uvre du
  copier/coller dans les interfaces graphiques
• La copie de prototype est au cur de la
  simulation des classes en Javascript

59
Autres Schémas Structuraux

• Présentation alphabétique

60
Schémas Structuraux

• Adapter
• 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

61
Bridge

• Découpler une abstraction de son implantation

62
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"

63
Decorator

• Attacher des fonctionnalités dynamiquement

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

65
Façade

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

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

67
Flyweight

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

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

69
Proxy

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

70
Proxy exemples

• interface des EJB

71
Autres schémas dynamiques

• Présentation alphabétique

72
Schémas Dynamiques

• Chain of Responsibility
• 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

73
Schémas Dynamiques

• Observer
• 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

74
Chain of Responsibility

• Eviter de coupler le demandeur d'une requête et
  son récepteur

75
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

76
Interpreter

• Explorer un arbre syntaxique

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

78
Mediator

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

79
Mediator
80
Mediator exemples

• Dans une interface graphique, gérer des
  dépendances complexes entre des composants de
  saisie/visualisation

81
Memento

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

82
Observer

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

83
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

84
State

• Gérer les états par une hiérarchie de classes

85
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

86
Strategy

• Varier dynamiquement les algorithmes

87
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

88
Visitor

• Explorer une structure de données hiérarchique

89
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

90
Autres Patterns Utiles
91
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
• http//www.theserverside.com/tt/articles/article.t
  ss?lSpringFramework
• le projet Pico (http//www.picocontainer.org/)
• le projet Avalon

92
Inversion de Dépendance par les setters
93
Inversion de Dépendancepar les constructeurs
94
Patterns Aggrégés
95
Model View Controller
96
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.

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

98
GRASP

• General Responsibility Assignment Software
  Patterns or Principles

99
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é

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

101
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

102
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

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

104
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

105
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

106
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

107
Indirection

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

108
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

109
Trois principes liés aux design et grasp patterns
110
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

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

112
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" 

113
Design Patterns J2EE
114
Les Patterns J2EE

• Java a popularisé une liste de Patterns utilisés
  dans la mise en uvre d'applications à base
  d'EJBChaque 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

115
http//java.sun.com/blueprints/corej2eepatterns/P
atterns/index.html
116
http//java.sun.com/blueprints/corej2eepatterns/P
atterns/index.html
117
http//java.sun.com/blueprints/patterns/catalog.h
tml

• 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

118
Références

• Mastering EJB 3.0
• http//www.theserverside.com/tt/books/wiley/master
  ingEJB3/index.tss
• EJB Design Patterns
• http//www.theserverside.com/tt/books/wiley/EJBDes
  ignPatterns/index.tss
• L'ensemble du site est utile
• http//www.theserverside.com/

119
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

120
Autres Pseudo Patterns référencés
121
Casting Method

• Prédéfinir les casts

122
Connected Group

• Gérer collectivement les connexions

123
Double Checked Locking

• class Singleton
• public
• static Singleton instance()
• private
• static Singleton self
• static SEMAPHORE key
• Singleton
• Singletoninstance()
• if (self 0)
• if ( lock(key) gt 0 )
• if (self 0 ) //double-check!
• self new Singleton
• unlock (key)

124
Flexible Service

• Faire d'une fonction une classe, évaluée de
  manière retardée

125
Intelligent Children

• Eviter les down casts

126
Is Kind Of

• Fournir des informations de type

127
Multiton

• class User
• public
• static const User LogIn(const char name,
• const char
  password)
• protected
• virtual User Lookup(const char name)
• private
• ListltUserNamegt _instances
• class UserName public ListItem
• User instance
• char name

128
Mutual Friends

• Représenter une relation bidirectionnelle

129
Named Object
130
Null Object

• Représenter une relation partielle

131
Objectifier

• Permettre à un objet de faire varier
  dynamiquement son comportement

132
RTTIVisitor

• Obtenir un cast sûr au moyen du pattern visitor

133
Sender Argument

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

134
Serializer

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

135
Timed Relationship

• Représenter une relation qui varie au cours du
  temps