Design Patterns

Présenté par Eric TOGUEM

Introduction

2

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

Qui suis je?

4

Eric Joël TOGUEM

CIO à AByster Inc.

Leader de CamerJUG,

Certifications: OCPJP 6, OCEJPAD6,

eric.toguem@abyster.com

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

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

Design pattern créationnels

Définissent des mécanismes pour l'instanciation et/ou

l'initialisation d'objets

7

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

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

Fabrique Abstraite (Abstract factory)

10

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

Monteur (Builder)

12

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

Fabrique (Factory Method)

14

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

Prototype (Prototype)

16

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

Singleton (Singleton)

18

Designs pattern structuraux

Organisent les interfaces/classes entre elles

19

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

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

Adaptateur (Adapter ou Wrapper)

22

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

Pont (Bridge ou Handle/Body)

24

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

Composite (Composite)

26

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

Décorateur (Decorator ou Wrapper)

28

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

Façade (Facade)

30

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

Poids-Mouche (Flyweight)

32

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

Proxy (Proxy ou Surrogate)

34

Design patterns

Comportementaux

Définissent la communication entre les classes et leurs

responsabilités

35

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

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

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

Chaîne de responsabilité (Chain of

responsibility)

39

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

Commande (Command, Action ou

Transaction)

41

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

Interpréteur (Interpreter)

43

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

Itérateur (Iterator ou Cursor)

45

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

Médiateur (Mediator)

47

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

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

son état depuis le Memento. 49

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

Observateur (Observer)

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

51

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

Etat (State)

53

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

Stratégie (Strategy)

La partie cliente configure un objet ClasseUtilisantStrategie avec un objet Strategie

et appelle la méthode de ClasseUtilisantStrategie qui utilise la stratégie. 55

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

Patron de méthode (Template method)

La partie cliente appelle la méthode de AbstractClasse qui définit l'algorithme 57

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

Visiteur (Visitor)

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

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