Le document présente les design patterns, un concept essentiel en informatique, issu principalement des travaux de Christopher Alexander et formalisé par le livre de 1995 des 'gang of four'. Il categorise les design patterns en trois types : créationnels, structuraux et comportementaux, et fournit des exemples et descriptions de chaque pattern. Les design patterns permettent d'améliorer la qualité du développement logiciel et de réduire la durée des projets en offrant des solutions éprouvées à des problèmes de conception.

1. Design Patterns
Présenté par Eric TOGUEM

2. Introduction
2

3. Origines
 Issus des travaux de l'architecte Christopher Alexander
(patrons en architecture des bâtiments)
 1995: Parution du livre "Design Patterns -- Elements of
Reusable Object-Oriented Software",
 Gang Of Four (Erich Gamma, Richard Helm, Ralph Johnson et
John Vlissides),
 Présente 23 Design Patterns
3

4. Qui suis je?
 Eric Joël TOGUEM
 CIO à AByster Inc.
 Leader de CamerJUG,
 Certifications: OCPJP 6, OCEJPAD6,
 eric.toguem@abyster.com
4

5. Design Pattern?
 Description d'une solution à un problème de conception
 "Prouvé » s'il a pu être utilisé dans au moins 3 cas
 Permettent d'améliorer la qualité de développement et
d'en diminuer la durée
5

6. Design Pattern: 3 catégories
 Créationnels : Définissent des mécanismes pour
l'instanciation et/ou l'initialisation d'objets
 Structuraux : Organisent les interfaces/classes entre
elles
 Comportementaux : Définissent la communication
entre les classes et leurs responsabilités
6

7. Design pattern créationnels
Définissent des mécanismes pour l'instanciation et/ou
l'initialisation d'objets
7

8. 5 design patterns créationnels
 Fabrique Abstraite: Isole l'appartenance à une famille
de classes
 Monteur: Isole les variations de représentations d'un
objet
 Fabrique: Isole l'instanciation d'une classe concrète
 Prototype: Isole l'appartenance à une classe
 Singleton: Isole l'unicité d'une instance.
8

9. Fabrique Abstraite (Abstract factory)
 Objectif: Fournir une interface pour créer des objets
d'une même famille sans préciser leurs classes concrètes.
 Quand Utiliser: Le système utilise des objets qui sont
regroupés en famille.
 Exemple: pour un look and feel donné, tous les
graphiques créés doivent être de la même famille
 Résultat : Isole l'appartenance à une famille de classes.
9

10. Fabrique Abstraite (Abstract factory)
10

11. Monteur (Builder)
 Objectifs:
 Séparer la construction d'un objet complexe de sa
représentation.
 Permettre d'obtenir des représentations différentes avec le
même procédé de construction.
 Quand Utiliser: Le système doit instancier des objets
complexes,
 Exemple: Différentes fenêtres d’une IHM,
 Résultat: Isole les variations de représentations d'un
objet
11

12. Monteur (Builder)
12

13. Fabrique (Factory Method)
 Objectifs: Déléguer l'instanciation aux sous-classes.
 Quand Utiliser: Au niveau d’une classe, on ne connaît
pas la classe exacte à instancier,
 Exemple: Classe réalisant une sauvegarde dans un flux
sortant, mais ne sachant pas s'il s'agit d'un fichier ou d'une
sortie sur le réseau,
 Résultat: Isole l'instanciation d'une classe concrète.
13

14. Fabrique (Factory Method)
14

15. Prototype (Prototype)
 Objectifs: Créer un nouvel objet à partir d’un
prototype.
 Quand Utiliser: Le système doit créer de nouvelles
instances, mais il ignore de quelle classe. Il dispose
cependant d'instances de la classe désirée.
 Exemple: Cas d'un logiciel de DAO comportant un
copier-coller,
 Résultat: Isole l'appartenance à une classe.
15

16. Prototype (Prototype)
16

17. Singleton (Singleton)
 Objectifs
 Restreindre le nombre d' instances d'une classe à une seule.
 Fournir une méthode pour accéder à cette instance unique.
 Quand Utiliser: La classe ne doit avoir qu'une seule
instance.
 Exemple: Cas d'une ressource système,
 Résultat: Isole l'unicité d'une instance.
17

18. Singleton (Singleton)
18

19. Designs pattern structuraux
Organisent les interfaces/classes entre elles
19

20. 7 designs pattern structuraux
 Adaptateur: Convertir l'interface d'une classe dans une autre
interface comprise par la partie cliente
 Pont: Découpler l'abstraction d'un concept de son
implémentation
 Composite: Permettre à la partie cliente de manipuler un
objet unique et un objet composé de la même manière
 Décorateur: Ajouter dynamiquement des responsabilités à
un objet
 Façade: Fournir une interface unique en remplacement d'un
ensemble d'interfaces d'un sous-système
 Poids-Mouche: Utiliser le partage pour gérer efficacement un
grand nombre d'objets de faible granularité
 Proxy: Fournir un intermédiaire entre la partie cliente et un
objet pour contrôler les accès à ce dernier
20

21. Adaptateur (Adapter ou Wrapper)
 Objectifs: Convertir l'interface d'une classe dans une
autre interface comprise par la partie cliente.
 Quand Utiliser: Le système doit intégrer un sous-
système existant. Ce sous-système a une interface non
standard par rapport au système.
 Exemple: Cas d’un driver bas niveau fournit par le
fabricant ne correspondant pas à l'interface utilisée par le
système pour d'autres drivers.
 Résultat: Isole l'adaptation d'un sous-système.
21

22. Adaptateur (Adapter ou Wrapper)
22

23. Pont (Bridge ou Handle/Body)
 Objectifs: Découpler l'abstraction d'un concept de son
implémentation.
 Quand Utiliser: Le système comporte une couche bas
niveau réalisant l'implémentation et une couche haut niveau
réalisant l'abstraction. Il est nécessaire que chaque couche soit
indépendante.
 Exemple: Système d'édition de documents d'une application.
Pour l'implémentation, l'édition aboutit à une sortie
imprimante, une image sur disque, un document PDF, etc. Pour
l'abstraction, il s'agit d'édition de factures, de rapports de stock
ou de courriers divers.
 Résultat: Isole le lien entre une couche de haut niveau et
celle de bas niveau.
23

24. Pont (Bridge ou Handle/Body)
24

25. Composite (Composite)
 Objectifs: Permettre à la partie cliente de manipuler un
objet unique et un objet composé de la même manière.
 Quand Utiliser: Le système comporte une hiérarchie
avec un nombre de niveaux non déterminé. Il faut pouvoir
considérer un groupe d'éléments comme un élément
unique.
 Exemple: Logiciel de DAO, plusieurs éléments
graphiques peuvent être regroupés en un nouvel élément
graphique.
 Résultat: Isole l'appartenance à un agrégat.
25

26. Composite (Composite)
26

27. Décorateur (Decorator ou Wrapper)
 Objectifs: Ajouter dynamiquement des responsabilités à
un objet.
 Quand Utiliser: Il est nécessaire de pouvoir étendre les
responsabilités d'une classe sans avoir recours au sous-
classage.
 Exemple: Cas d'une classe gérant des d'entrées/sorties à
laquelle on souhaite ajouter un buffer et des traces de
log.
 Résultat: Isole les responsabilités d'un objet.
27

28. Décorateur (Decorator ou Wrapper)
28

29. Façade (Facade)
 Objectifs: Fournir une interface unique en remplacement
d'un ensemble d'interfaces d'un sous-système.
 Quand Utiliser: Le système comporte un sous-système
complexe avec plusieurs interfaces, certaines présentant
des opérations pas utiles au reste du système.
 Exemple: Cas d'un sous-système communiquant avec
des outils de mesure.
 Résultat: Isole les fonctionnalités d'un sous-système
utiles à la partie cliente.
29

30. Façade (Facade)
30

31. Poids-Mouche (Flyweight)
 Objectifs: Utiliser le partage pour gérer efficacement un
grand nombre d'objets de faible granularité.
 Quand Utiliser: Un système utilise un grand nombre d'
instances. Chacune de ces instances a des attributs
propre au contexte et propre à l'objet.
 Exemple: Cas caractéristiques des traits dans un logiciel
de DAO. Les caractéristiques d'épaisseur, d'ombre sont
intrinsèques, et les coordonnées sont extrinsèques.
 Résultat: Isole les propriétés partageables des objets.
31

32. Poids-Mouche (Flyweight)
32

33. Proxy (Proxy ou Surrogate)
 Objectifs: Fournir un intermédiaire entre la partie
cliente et un objet pour contrôler les accès à ce dernier.
 Quand Utiliser: Les opérations d'un objet sont
coûteuses en temps ou sont soumises à une gestion de
droits d'accès.
 Exemple: Cela peut être un système de chargement d'un
document (gestion droits d’accès).
 Résultat: Isole le comportement lors de l'accès à un
objet.
33

34. Proxy (Proxy ou Surrogate)
34

35. Design patterns
Comportementaux
Définissent la communication entre les classes et leurs
responsabilités
35

36. 11 design patterns Comportementaux
(1/2)
 Chaîne de responsabilité: Eviter le couplage entre l'
émetteur d'une requête et son récepteur en donnant à plus
d'un objet une chance de traiter la requête
 Commande : Paramétrer facilement des requêtes diverses.
 Interpréteur : Définir une représentation de la grammaire
d'un langage.
 Itérateur : Fournir un moyen de parcourir séquentiellement
les éléments d'un objet composé.
 Médiateur : Gérer la transmission d'informations entre des
objets interagissant entre eux
 Memento : Sauvegarder l' état interne d'un objet en
respectant l' encapsulation, afin de le restaurer plus tard.
36

37. 11 design patterns Comportementaux
(2/2)
 Observateur : Prévenir des objets observateurs,
enregistrés auprès d'un objet observé, d'un événement
 Etat : Changer le comportement d'un objet selon son
état interne.
 Stratégie : Définir une famille d' algorithmes
interchangeables, indépendamment de la partie cliente.
 Patron de méthode : Définir le squelette d'un
algorithme en déléguant certaines étapes à des sous-
classes.
 Visiteur : Séparer un algorithme d'une structure de
données.
37

38. Chaîne de responsabilité (Chain of
responsibility)
 Objectifs: Eviter le couplage entre l' émetteur d'une
requête et son récepteur en donnant à plus d'un objet
une chance de traiter la requête.
 Quand Utiliser: Le système doit gérer un requête. La
requête implique plusieurs objets pour la traiter.
 Exemple: Cas d'un système complexe d'habilitations
possédant plusieurs critères afin d'autoriser l'accès. Ces
critères peuvent varier en fonction de la configuration.
 Résultat: Isole les différentes parties d'un traitement.
38

39. Chaîne de responsabilité (Chain of
responsibility)
39

40. Commande (Command, Action ou
Transaction)
 Objectifs:
 Encapsuler une requête sous la forme d' objet.
 Paramétrer facilement des requêtes diverses.
 Permettre des opérations réversibles
 Quand Utiliser: Le système doit traiter des requêtes,
pouvant provenir de plusieurs émetteurs et pouvant être
annulées.
 Exemple: cas d'une IHM avec des boutons de
commande, des raccourcis clavier et des choix de menu
aboutissant à la même requête.
 Résultat: Isole une requête.
40

41. Commande (Command, Action ou
Transaction)
41

42. Interpréteur (Interpreter)
 Objectifs:
 Définir une représentation de la grammaire d'un langage.
 Utiliser cette représentation pour interpréter les éléments de
ce langage.
 Quand Utiliser: Le système doit interpréter un langage.
 Exemple: Cas d'un logiciel embarqué dont la
configuration des écrans serait stockée dans des fichiers
XML.
 Résultat: Isole les éléments d'un langage.
42

43. Interpréteur (Interpreter)
43

44. Itérateur (Iterator ou Cursor)
 Objectifs: Fournir un moyen de parcourir
séquentiellement les éléments d'un objet composé.
 Quand Utiliser: Le système doit parcourir les éléments
d'un objet complexe,
 Exemple: Cas des classes représentant des listes et des
ensembles en Java.
 Résultat: Isole le parcours d'un agrégat.
44

45. Itérateur (Iterator ou Cursor)
45

46. Médiateur (Mediator)
 Objectifs: Gérer la transmission d'informations entre
des objets interagissant entre eux.
 Quand Utiliser: Différents objets ont des interactions.
Un événement sur l'un provoque une (ou des) action(s)
sur un (ou d‘)autre(s) objets,
 Exemple: Cas des éléments d'IHM. Si une case est
cochée, certains éléments deviennent accessibles.
 Résultat: Isole la communication entre des objets.
46

47. Médiateur (Mediator)
47

48. Memento (Memento)
 Objectifs: Sauvegarder l' état interne d'un objet en
respectant l' encapsulation, afin de le restaurer plus tard.
 Quand Utiliser: Un système doit conserver et restaurer
l'état d'un objet. L'état interne de l'objet à conserver n'est
pas visible par les autres objets.
 Exemple: Cas d’un éditeur de document disposant d'une
fonction d'annulation
 Résultat: Isole la conservation de l'état d'un objet.
48

49. Memento (Memento)
La partie cliente demande au Createur de stocker son état dans un Memento. Elle
demande au Gardien de conserver ce Memento. Elle peut alors demander au Gardien de
lui fournir un des Memento conservés, ou bien elle demande au Createur de restituer
49
son état depuis le Memento.

50. Observateur (Observer)
 Objectifs: Prévenir des objets observateurs, enregistrés
auprès d'un objet observé, d'un événement.
 Quand Utiliser: Un objet doit connaitre les
changements d' état d'un autre objet. L'objet doit être
informé immédiatement.
 Exemple: Cas d'un tableau affichant des statistiques. Si
une nouvelle donnée est entrée, les statistiques sont
recalculées
 Résultat: Isole un algorithme traitant un événement.
50

51. Observateur (Observer)
La partie cliente indique à l'objet Observe les objets Observateur qu'il avertira.
51

52. Etat (State)
 Objectifs: Changer le comportement d'un objet selon
son état interne.
 Quand Utiliser: Un objet a un fonctionnement différent
selon son état interne.
 Exemple: Cas d’un document informatique. Il a comme
fonctions ouvrir, modifier. Le comportement de ces
méthodes change selon l'état du document
 Résultat: Isole les algorithmes propres à chaque état
d'un objet.
52

53. Etat (State)
53

54. Stratégie (Strategy)
 Objectifs: Définir une famille d' algorithmes
interchangeables, indépendamment de la partie cliente.
 Quand Utiliser: Un objet doit pouvoir faire varier une
partie de son algorithme.
 Exemple: Cas d’un Cela peut être une liste triée. Le tri
peut être alphabétique, inverse, les majuscules avant les
miniscules, …
 Résultat: Isole les algorithmes appartenant à une même
famille d'algorithmes.
54

55. Stratégie (Strategy)
La partie cliente configure un objet ClasseUtilisantStrategie avec un objet Strategie
55
et appelle la méthode de ClasseUtilisantStrategie qui utilise la stratégie.

56. Patron de méthode (Template method)
 Objectifs: Définir le squelette d'un algorithme en
déléguant certaines étapes à des sous-classes.
 Quand Utiliser: Une classe possède un fonctionnement
global. Mais les détails de son algorithme doivent être
spécifiques à ses sous-classes.
 Exemple: Cas d'un document informatique qui peut être
sauvegardé. Selon le type de document, il ne sera pas
sauvegardé de la même manière, …
 Résultat: Isole les parties variables d'un algorithme.
56

57. Patron de méthode (Template method)
La partie cliente appelle la méthode de AbstractClasse qui définit l'algorithme
57

58. Visiteur (Visitor)
 Objectifs: Séparer un algorithme d'une structure de
données.
 Quand Utiliser: Il est nécessaire de réaliser des
opérations, sur les éléments d'un objet structuré, qui
varient en fonction de la nature de chaque élément et
peuvent être de plusieurs types.
 Exemple: Cas d'un logiciel d'images de synthèse. L'image
composée de plusieurs objets : sphère, polygone, etc... Sur
chaque élément, il faut effectuer plusieurs opérations
pour le rendu : ajout des couleurs, effet d'éclairage, …
 Résultat: Isole les algorithmes appliquées sur des
structures de données
58

59. Visiteur (Visitor)
La partie cliente appelle les méthodes de réception d'un Visiteur des Element.
59

60. Références
 http://rpouiller.developpez.com/tutoriel/java/design-
patterns-gang-of-four/
 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
(trad. Jean-Marie Lasvergères), Design Patterns - Catalogue
de modèles de conceptions réutilisables
60