Design patterns - Exemples en Java

OUSSAMA BEN KHIROUN

1

PATRONS DE CONCEPTION (DESIGN PATTERNS)

Exemples en Java

INTRODUCTION

Un patron de conception est un arrangement caractéristique de modules, reconnucomme bonne pratique en réponse à un problème de conception d'un logiciel. Ildécrit une solution standard, utilisable dans la conception de différents logiciels.

[Wikipedia]

« Chaque patron décrit un problème qui se manifeste constamment dans notreenvironnement, et donc décrit le cœur de la solution à ce problème, d’une façon telleque l’on puisse réutiliser cette solution des millions de fois, sans jamais le faire deuxfois de la même manière »

[Christopher Alexander, 1977]

2

HISTORIQUE (1/2)

3

À l’origine des travaux de l'architecte ChristopherAlexander

Intitulé : « A Pattern Language »

Année : les années 70

HISTORIQUE (2/2)

Formalisés dans le livre du « Gang of Four » GoF

(Erich Gamma, Richard Helm, Ralph Johnson et JohnVlissides)

Intitulé : « Design Patterns – Elements of ReusableObject-Oriented Software »

Année : 1995

Décrit 23 patrons (« patrons GoF »)

4

MOTIVATION & OBJECTIFS

Modularité – Facilité de gestion (programmation objet)

Cohésion

• Degré avec lequel les tâches réalisées par un seul module sont fonctionnellement reliées

• Une forte cohésion est une bonne qualité

Couplage

• Degré d’interaction entre les modules dans le système

• Un couplage « lâche » est une bonne qualité

Réutilisabilité – Bibliothèques, frameworks

5

CATÉGORIES DE DESIGN PATTERNS

• comment faire l'instanciation et la configuration des classes et des objets

Modèle de Création (Creational)

• comment organiser les classes d'un programme dans une structure plus large (séparant l'interface de l'implémentation)

Modèle de Structure (Structural)

• comment organiser les objets pour que ceux-ci collaborent (distribution des responsabilités)

Modèle de Comportement (Behavioral)

6

ANTI PATTERNS (À NE PAS FAIRE)

Ancre de bateau : un composant inutilisémais qui est gardé dans le logiciel pourdes raisons politiques, en pensant que cecode servira plus tard.

Attente active, Inter-blocages et famine

Erreur de copier/coller : La duplicationde code sans vérification entraîne desincohérences. La meilleure solution étantencore de factoriser les partiescommunes au lieu de les dupliquer.

Réinventer la roue : il est souventrecommandé d’opter pour la réutilisation

Programmation spaghetti : Ceci fait

référence à l'image d'un plat despaghetti, dans lequel il serait impossiblede modifier une petite partie du logicielsans altérer le fonctionnement de tous lesautres composants.

Architecture As Requirements :consistant à spécifier une architecture parsimple préférence ou parce qu'elle estnouvelle, alors qu'il n'y en a pas besoin etque le client n'en a pas exprimé le désir.

Architecture By Implication : consistant àne pas documenter l'architecture utiliséepar un projet et à ne pas la spécifier.

7

8

CATÉGORIE DE MODÈLES DE CRÉATION

Ces modèles sont très courants

pour déléguer à d'autres classes

la construction des objets.

9

FactorySingleton

PrototypeAbstract Factory

Builder

SINGLETON (1/2)

Un singleton sert à contrôler le nombre d'instances d'une classe présent à unmoment donné. C'est souvent très pratique pour les classes sans état eteffectuant toujours les mêmes traitements.

Exemple : classe de connexion à une Base de Données

Il est utilisé lorsque l'on a besoin d'exactement de un objet (ou N ) pourcoordonner des opérations dans un système.

10

CREATION

Question : Comment faire en Java pour empêcher l’instanciation de plus

d'un objet d'une classe donnée ?

SINGLETON (2/2)

11

CREATION

OU

FACTORY (OU FABRIQUE ) (1/3)

Sert à instancier facilement des objets appartenant à des classes dérivés d'une même super classe ou implémentant des interfaces communs.

Dans ce type de patron on trouve : le client, la ou les fabriques et la ou les produits

12

CREATION

Question : Comment faire en Java pour faciliter à un client l'instanciation

d'objets filles d'une même classe mère ou implémentant une même

interface ?

FACTORY (OU FABRIQUE ) : EXEMPLE (2/3)

13

CREATION

FACTORY (3/3)

14

CREATION

BUILDER (OU MONTEUR ) (1/2)

C'est une classe offrant des méthodes facilitant la création d'un objet composé d'un ensemble d'objets sources.

Exemple : pour construire un dessin il faut ajouter des points, des lignes, des cercles

Il ne doit pas être confondu avec la Fabrique.

15

CREATION

BUILDER (OU MONTEUR ) (2/2)

16

CREATION

CATÉGORIE DE MODÈLES DE STRUCTURE

Ces modèles tentent de

composer des classes pour bâtir

de nouvelles structures.

17

Adapter

FacadeComposite

Bridge FlyweightDecoratorProxy

COMPOSITE

18

STRUCTURE

OBJECTIFS :

Organiser les objets en structure arborescente afin dereprésenter une hiérarchie.

Permettre à la partie cliente de manipuler un objet unique etun objet composé de la même manière.

RESPONSABILITES :

•Composant : définit l'interface d'un objet pouvant être uncomposant d'un autre objet de l'arborescence.

•Element : implémente un objet de l'arborescence n'ayant pasd'objet le composant.

•Composite : implémente un objet de l'arborescence ayant un ou desobjets le composant.

•La partie client manipule les objets par l'interface Composant.

Exemple : Modélisation tâche

élémentaire et tâche complexe

FACADE (1/2)

OBJECTIFS :

Fournir une interface unique enremplacement d'un ensembled'interfaces d'un sous-système.

Définir une interface de haut niveaupour rendre le sous-système plussimple d'utilisation.

19

STRUCTURE

FACADE (2/2) : EXEMPLE

20

STRUCTURE"Facade" Présente certaines fonctionnalités.

Dans ce cas, ne présente que la méthode

"operation2()" de "ClasseA" et la méthode

"operation41()" utilisant "operation4()" de

"ClasseB" et "operation1()" de "ClasseA".

CATÉGORIE DE MODÈLES DE COMPORTEMENT

Ces modèles tentent de répartir

les responsabilités entre chaque

classe.

21

Template Iterator

Command Mediator

Memento

InterpreterChain of

Responsibility

ObserverStateStrategy Visitor

TEMPLATE (1/2)

OBJECTIFS :

Définir le squelette d'un algorithme en déléguant certainesétapes à des sous-classes.

RESPONSABILITES :

• AbstractClasse : définit des méthodes abstraites primitives.La classe implémente le squelette d'un algorithme quiappelle les méthodes primitives.

• ConcreteClasse : est une sous-classe concrète deAbstractClasse. Elle implémente les méthodes utilisées parl'algorithme de la méthode operationTemplate() deAbstractClasse.

• La partie cliente appelle la méthode de AbstractClasse quidéfinit l'algorithme.

22

COMPORTEMENT

TEMPLATE (2/2) : EXEMPLE

23

COMPORTEMENT

ITERATOR

Voir utilisation des itérateurs en Java :

Classe « Iterator », Interface « Iterable »

24

COMPORTEMENT

RÉFÉRENCES

[1] Régis POUILLER, « Design Patterns du Gang of Four appliqués à Java ». Developpez.com : http://rpouiller.developpez.com/tutoriel/java/design-patterns-gang-of-four/

[2] Mark Grand, « Patterns in Java: A Catalog of Reusable Design Patterns Illustrated with UML », volume 1. Wiley, 2 édition, 2002.

25