Java Entreprise Et Les Design Patterns 2 0 2007 French

Java entreprise et les design
patterns
Version 2.0
Arnaud BARBE Page 1 sur 109

Conception objet et Design Patterns avec Java
1 OBJECTIF 6
2 PATTERNS 7
2.1 OBJECTIFS 7
2.2 DESCRIPTION 7
2.3 AVANTAGES 7
2.4 INCONVENIENTS 7
2.5 GENERAL RESPONSABILITY ASSIGNEMENT SOFTWARE PATTERNS [GRASP] 8
2.5.1 PRESENTATION 8
2.5.2 PATTERNS FONDAMENTAUX 8
2.5.2.1 Expert 8
2.5.2.2 Low coupling 9
2.5.2.3 High cohesion 10
2.5.2.4 Creator 11
2.5.3 PATTERNS SPECIFIQUES 11
2.5.3.1 Controller 11
2.5.3.2 Polymorphism 12
2.5.3.3 Pure Fabrication 13
2.5.3.4 Indirection 14
2.5.3.5 Law of Demeter 14
2.6 DESIGN PRINCIPLES 15
2.6.2 GESTION DES EVOLUTIONS ET DES DEPENDANCES ENTRE CLASSES 15
2.6.2.1 Open/Closed principle 15
2.6.2.2 Liskov substitution principle 16
2.6.2.3 Dependency inversion principle 16
2.6.2.4 Interface segregation principle 17
2.6.3 ORGANISATION DE L’APPLICATION EN MODULES 18
2.6.3.1 Reuse/Release equivalence principle 18
2.6.3.2 Common reuse principle 19
2.6.3.3 Common closure principle 19
2.6.4 GESTION DE LA STABILITE DE L’APPLICATION 20
2.6.4.1 Acyclic dependencies principle 20
2.6.4.2 Stable dependencies principle 20
2.6.4.3 Stable abstractions principle 21
2.6.5 CONCLUSION 21
2.7 GANG OF FOUR [GOF] 22
2.7.2 PATTERNS DE CREATION 22
2.7.2.1 Abstract Factory 22
2.7.2.2 Builder 23
2.7.2.3 Factory Method 24
2.7.2.4 Prototype 26
2.7.2.5 Singleton 27
2.7.3 PATTERNS DE STRUCTURE 28
2.7.3.1 Adapter 28
2.7.3.2 Bridge 29
2.7.3.3 Composite 30
2.7.3.4 Decorator 32
2.7.3.5 Facade 33
Arnaud BARBE 2 / 109
2.7.3.6 FlyWeight 34

2.7.3.7 Proxy 37
2.7.4 PATTERNS DE COMPORTEMENT 38
2.7.4.1 Chain of Responsability 38
2.7.4.2 Command 39
2.7.4.3 Interpreter 41
2.7.4.4 Iterator 42
2.7.4.5 Mediator 43
2.7.4.6 Memento 44
2.7.4.7 Observer 45
2.7.4.8 State 47
2.7.4.9 Strategy 48
2.7.4.10 Template Method 50
2.7.4.11 Visitor 51
2.8 PATTERN JEE 52
2.8.1 BUSINESS DELEGATE 52
2.8.1.1 Problème 52
2.8.1.2 Solution 52
2.8.1.3 Implémentation 53
2.8.2 SERVICE LOCATOR 53
2.8.2.2 Solution 54
2.8.3 SESSION FACADE 56
2.8.3.2 Solution 56
2.8.4 MESSAGE FACADE / SERVICE ACTIVATOR 57
2.8.4.2 Solution 58
2.8.5 TRANSFER OBJECT / VALUE OBJECT 58
2.8.5.2 Solution 59
2.8.6 TRANSFER OBJECT ASSEMBLER / VALUE OBJECT ASSEMBLER 60
2.8.6.2 Solution 60
2.8.7 VALUE LIST HANDLER 61
2.8.7.2 Solution 61
2.8.8 DATA ACCESS OBJECT 62
2.8.8.2 Solution 62
2.8.9 CONCLUSION 63
3 ANTI-PATTERNS 64
3.1 CODE SOURCE 64

3.1.1 CODE COURT 64
3.1.2 OPTIMISATION 64

3.1.3 COPIER/COLLER 64
3.1.4 VARIABLES 64
3.1.5 CONCATENATION DE CHAINES DE CARACTERES 64
3.1.6 COHERENCE DU SYSTEME 64
3.1.7 TYPAGE FORT/FAIBLE 65
3.1.8 SYNCHRONIZED 66
3.1.9 DOCUMENTATION 67
3.1.10 EXCEPTION 67
3.1.11 PARAMETRES DE METHODES 67
3.2 PRINCIPES 68
3.2.1 RESSOURCES 68
3.2.2 HERITAGE 68
3.2.3 HABITUDE 69
3.2.4 SIMPLICITE 69
3.3 MEMOIRE 69
3.3.1 DUREE DE VIE DES OBJETS 69
3.3.2 ALLOCATION MEMOIRE 69
3.4 CONCEPTION 69
3.4.1 THE GOD CLASS 69
3.4.2 SWISS ARMY KNIFE 70
3.4.3 LAVA FLOW 70
3.4.4 NO OO 70
3.4.5 PROLIFERATION OF CLASSES 70
3.4.6 GOLDEN HAMMER 71
3.4.7 SPAGHETTI CODE 71
3.4.8 REINVENT THE WHEEL 71
4 CONCLUSION 72
4.1 A RETENIR 72
4.2 ET APRES ? 72
4.3 CODE SOURCE 72
4.3.1 CREATION 72
4.3.1.1 AbstractFactory 72
4.3.1.2 Builder 74
4.3.1.3 FactoryMethod 75
4.3.1.4 Prototype 76
4.3.1.5 Singleton 76
4.3.2 STRUCTURE 77
4.3.2.1 Adapter 77
4.3.2.2 Bridge 77
4.3.2.3 Composite 79
4.3.2.4 Decorator 81
4.3.2.5 Facade 83
4.3.2.6 Flyweight 84
4.3.2.7 Proxy 86
4.3.3 COMPORTEMENT 88
4.3.3.1 Chain of responsability 88
4.3.3.2 Command 89
4.3.3.3 Interpreter 91
4.3.3.4 Iterator 94
4.3.3.5 Mediator 95
4.3.3.6 Memento 97
4.3.3.7 Observer 98

4.3.3.8 State 100

4.3.3.9 Strategy 103
4.3.3.10 Template Method 105
4.3.3.11 Visitor 105
5 L’AUTEUR 109

1 OBJECTIF
Ce document est un condensé de ce qui aujourd’hui (et pour moi) semble essentiel dans le monde
java et celui des systèmes d’informations d’entreprises. Il est orienté conception et (l’un ne va pas
sans l’autre) design patterns. C’est un résumé de mes expériences professionnelles passées, des
articles et livres lus. Mon travail n’a pas été de créer un énième article ou livre sur java et
l’entreprise mais plutôt de regrouper un savoir éparpillé au travers d’écrits de personnalités
brillantes comme Bertrand Meyer, Craig LARMAN, Robert MARTIN, la bande des quatre et les
autres (pardon pour ceux que j’oublie).
Par avance je m’excuse des risques de plagiat difficile à éviter dans ce type d’exercice de
transcription et de résumé. D’ailleurs, rendons à césar ce qui est à césar, je ne m’attribue en
aucune sorte le travail des personnes cités précédemment : je le répète mon travail se limite
uniquement à condenser des concepts ou des principes.

2 PATTERNS
2.1 Objectifs
Ce chapitre a pour but de présenter les Patterns au travers de 4 approches : les patterns
fondamentaux GRASP défini par Craig LARMAN, les « design principles » de Bertrand MEYER et
Robert MARTIN, nous aborderons ensuite les incontournables patterns du Gang Of Four (GOF)
développés par Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides pour terminer avec
les patterns JEE c'est-à-dire appliqués à la plateforme Java EE. Nous terminerons par un chapitre
sur les anti-patterns les plus courants. Les patterns seront décrit (section présentation) puis
agrémentés (section implémentation) de diagrammes adaptés au monde Java avec des exemples
concrets.
2.2 Description
Les designs patterns ont pour principal intérêt de décrire et de formaliser des problèmes
récurrents. Ils synthétisent le savoir-faire et l'expérience de leurs concepteurs face à des
problèmes bien définis.
Ils apportent un début de réponse à votre problème. Attention cependant à ne pas les confondre
avec un catalogue de solutions toutes prêtes : les design patterns constituent plutôt un guide.
L’application d’un pattern à une solution passe par une période d’adaptation au problème. C’est
comme si vous utilisiez des briques pour fabriquer un mur : vous possédez une forme de base qui
va vous permettre de construire plus vite que si vous aviez à fabriquer les briques vous-même.
Cependant lorsque le mur amorce un angle à 45°, il faudra découper certaines de vos briques.
Globalement vous gagnez du temps, mais il faut adapter.
Par conséquent, dans un contexte où les applications sont de plus en plus complexes, l'utilisation
des design patterns est un moyen de réduire les risques d'échec, puisque les solutions proposées
ont été "testées et approuvées" dans de nombreux projets. Les design patterns peuvent être
utilisés soit directement, en se conformant aux concepts et aux règles qui les caractérisent, soit
par l'intermédiaire de Frameworks qui les utilisent. Ils accélèrent la conception et les
développements tout en accroissant la qualité générale des applications produites, qualité
indispensable à la maintenabilité et aux transferts de compétence.
2.3 Avantages
L’élévation du niveau d’abstraction est le principal intérêt : moins de perte de temps en
explication, la complexité en est réduite. Le langage est commun et permet de représenter des
systèmes complexes sans se perdre dans les méandres de la technique et du langage. Ils offrent
une étape supplémentaire entre la conception et le code source. Globalement la qualité s’en
trouve amélioré puisqu’on s’appuie sur des concepts éprouvés.
2.4 Inconvénients
Le principal ennemi du design pattern c’est …le design pattern. En effet la construction par patron
demande un apprentissage de longue haleine, une habitude de lecture (issue essentiellement de
l’expérience) pour pouvoir les repérer ou les appliquer. Une application peut rapidement utiliser
plusieurs dizaines voir des centaines d’occurrences de pattern. A ce stade ils ont plutôt tendance à
se « noyer dans la masse » et ils deviennent difficiles à reconnaître. Il faut donc être prudent et
soigneux quant à la répartition en package et à la dénomination des classes pour faciliter leur
localisation. La problématique est de trouver à chaque fois le juste dosage entre l’intérêt de
l’utilisation d’un pattern et les inconvénients inhérents à son application.

2.5 General Responsability Assignement Software

Patterns [GRASP]
2.5.1Présentation
Le GRASP pour « patterns généraux d’affectation des responsabilités », propose des patterns
fondamentaux, issus essentiellement du bon sens du développeur. Ce sont des patterns simples et
basiques. Ils peuvent paraître « simplistes » pour des développeurs confirmés, mais ils sont la
base de toute bonne conception. D’ailleurs, nombre d’entre vous auront une impression de déjà vu
en les découvrant puisque nous les appliquons inconsciemment. Contrairement aux patterns du
GOF qui se rapprochent de cas concrets, les patterns GRASP sont plus abstraits. Ils ne sont en
aucun cas des modèles ou design patterns mais plutôt des principes de bonne conduite.
On distingue 9 patterns : les 4 premiers sont fondamentaux (Expert, Low coupling, High cohesion,
Creator), les 5 suivants sont plus spécifiques (Controller, Polymorphism, Pure Fabrication,
Indirection, Law of demeter).
2.5.2Patterns Fondamentaux
2.5.2.1 Expert
2.5.2.1.1 Théorie
Le pattern expert propose de déterminer les responsabilités en faisant appel au bon sens du
concepteur. Il s’agit d’affecter les responsabilités à une classe en fonction des informations dont
elle dispose (principe d’encapsulation) ou non (principe de collaboration). Dans le cas d’une
collaboration, plusieurs « experts fragmentaires » (ou classes) sont identifiés et collaborent
ensemble afin de remplir la responsabilité entière. Avec ce pattern les responsabilités seront donc
mis avec les données.
2.5.2.1.2 Implémentation
Dans l’exemple ci-dessous, nous effectuons une addition. Le client instancie un objet Addition et
prend la responsabilité de l’opération.
Addition
01 package com.arnbe.patterns.grasp.expert.bad;
02
03 public class Addition {
04 private int firstOp;
05 private int secondOp;
06
07 /**
08 * constructeur
09 * @param op1
10 * @param op2
11 */
12 public Addition(int op1, int op2) {
13 super();
14 firstOp = op1;
15 secondOp = op2;
16 }
17
18 /**
19 * @return
20 */
21 protected int getFirstOp() {
22 return firstOp;
23 }
24
25 /**
26 * @return
27 */
28 protected int getSecondOp() {
29 return secondOp;
30 }
31 }
Client
01 package com.arnbe.patterns.grasp.expert.bad;
02
03 public class Client {
04 public static void main(String[] args) {
05
06 Addition add = new Addition(4, 8);

07 int result = add.getFirstOp() + add.getSecondOp();

08 System.out.println(result);
09 }
10 }
Ce procédé n’est pas bon car il ne respecte pas la répartition des responsabilités. En effet
l’opération d’addition revient à la classe Addition et non au client. L’opération est ici simple (une
addition), mais dans le cas d’une opération plus complexe, le même code devra être maintenu
dans différent partie de l’application, entraînant des problèmes de maintenance, de test et voir de
performance.
Il serait plus correct d’écrire :
Addition
01 package com.arnbe.patterns.grasp.expert.good;
02
03 public class Addition {
04 private int firstOp;
05
06 private int secondOp;
07
08 /**
09 * constructeur
10 * @param op1
11 * @param op2
12 */
13 public Addition(int op1, int op2) {
14 super();
15 firstOp = op1;
16 secondOp = op2;
17 }
18
19 /**
20 * @return
21 */
22 protected int getFirstOp() {
23 return firstOp;
24 }
25
26 /**
27 * @return
28 */
29 protected int getSecondOp() {
30 return secondOp;
31 }
32
33 /**
34 * additionne et retourne le résultat
35 * @return
36 */
37 public int add() {
38 return firstOp + secondOp;
39 }
40 }
Client
01 package com.arnbe.patterns.grasp.expert.good;
02
03
04 public class Client {
05 public static void main(String[] args) {
06
07 Addition add = new Addition(4, 8);
08 System.out.println(add.add());
09 }
10 }
2.5.2.2 Low coupling

2.5.2.2.1 Théorie
Le pattern « faible couplage » propose de limiter le couplage entre objets. On entend par
couplage fort une association (délégation ou composition) ou un héritage. Les interdépendances
(ou couplage fort) entre éléments d’un système rendent la compréhension plus difficile et la
réutilisation quasi impossible. Un couplage faible facilite la réutilisation et la maintenance des
éléments du système avec peu d’effet de régression (principe de modularité). Ici il convient de
trouver le juste compromis entre des classes très dépendantes et un système peu communicant.
Dans le diagramme de classe suivant, un client possède des factures, et ces factures peuvent être
imprimées.
Figure 1 le Customer est couplé avec Invoice mais aussi avec le Printer
Il est préférable que l’Invoice ait la capacité de s’imprimer et que Customer ne connaisse pas
l’implémentation (utilisation de la classe Printer). Le diagramme suivant est plus proche de la
bonne solution.
Figure 2 Couplage plus faible
2.5.2.3 High cohesion

2.5.2.3.1 Théorie
Le pattern de forte cohésion tente de répondre à la problématique d’affectation des
responsabilités tout en conservant une complexité acceptable du système. Le but est de séparer
les responsabilités en domaine (fonctionnel, technique, etc.) afin de préserver la cohésion de la
classe. Finalement une classe cohésive est plus facile à comprendre car elle a un but bien
spécifique (assuré par la finesse de l’affectation des responsabilités) et donc facilement évolutive.
Attention à une cohésion trop forte (multiplication des classes) qui entraîne un couplage élevé
(beaucoup de classes collaborent entre elles). A l’inverse, une classe peu cohésive est difficile à
maintenir, à comprendre, à réutiliser et est globalement plus fragile car sensible à la variation.
Imaginons que notre système précédent doit assurer la persistance, la gestion et l’affichage du
Customer et de l’Invoice.
Figure 3 Exemple de faible cohésion
Dans cet exemple, la classe Customer doit endosser la responsabilité de l’affichage

(openCustomerWindow()), de la gestion et de la persistance de l’objet Customer
(saveCustomerInDB()). La cohésion de la classe est faible et les responsabilités trop concentrées.
Ce type de classe est souvent pénible à maintenir car chaque nouvelle fonctionnalité rend la classe
de plus en plus complexe.
A l’inverse une cohésion trop forte entraîne un couplage fort et donc une réutilisation quasi nulle.
Figure 4 Attention à une trop forte cohésion !!
Ici la cohésion est poussée à l’extrême, mais démontre bien les risques liés à une cohésion trop
forte. Toutefois si vous prenez l’option de rendre vos classes fortement cohésives, il est possible
d’en réduire le couplage avec le « monde extérieur » en utilisant une façade (cf. pattern Facade
du GOF).
2.5.2.4 Creator
2.5.2.4.1 Théorie
Le pattern Creator est relativement proche de l’Expert (en terme de répartition des
responsabilités), à une nuance près : le Creator possède uniquement la responsabilité de la
création d’un l’objet. Ceci va d’ailleurs dans le sens du pattern Low Coupling puisque la
responsabilité de la création peut être attribuée à une classe dédiée. En effet la création d’un
objet peut nécessiter la collaboration de plusieurs classes : dans ce cas seul le Creator possède
des dépendances multiples (cf. pattern abstract factory ou builder du GOF).
Dans le diagramme de collaboration suivant, Customer prend la responsabilité de la création des
Invoice qui prend à son tour la responsabilité de la création du Printer.
Figure 5 Répartition de la responsabilité de création
2.5.3Patterns Spécifiques
2.5.3.1 Controller
2.5.3.1.1 Théorie
Le pattern Controller propose de prendre en charge la responsabilité de la réception et du
traitement des messages systèmes. Par message système on entend tout message généré par un
acteur externe. Le Controller peut déléguer des tâches à d’autres objets, sont but étant plutôt de
coordonner les actions et les évènements. Il existe plusieurs types de Controller :

Facade Controller : point d’entrée unique vers un système ou sous système.

Use Case Controller : objet de contrôle pour un évènement système particulier.
Role Controller : élément du domaine ayant le rôle du contrôleur.
Finalement, il est préférable d’utiliser des classes Controller avec une cohésion forte : la classe ne
s’occupe que du traitement du message (redirection) et non de la logique métier associée (cf.
pattern Facade du GOF).
Dans le diagramme ci dessous l’implémentation d’un Facade Controller faisant l’interface entre le
client et un système sous jacent complexe et fortement couplé. L’intérêt est de limiter le couplage
du client vers le sous système et ainsi de faciliter la réutilisation ou le remplacement du sous
système par un autre. Il normalise par un point de passage de unique, les communications vers un
système.
Figure 6 Limitation du couplage par utilisation d’un Controller
2.5.3.2 Polymorphism
2.5.3.2.1 Théorie
Ce pattern utilise la variation de comportement de classe en fonction de leur type. Il apporte une
solution pour simuler des comportements ou des états sans avoir à modifier le client : c’est une
approche par composants enfichables. Cette solution est plus élégante car la cohésion est forte et
les risques de régression de l’ensemble faible en cas d’évolution applicative (cf. pattern Strategy
du GOF).
Dans notre exemple, le client utilise un véhicule. Dans ce cas de figure, peu importe que
l’implémentation soit une voiture, un avion ou un bateau. Il devient très simple alors d’ajouter de
nouveaux comportements. Chaque implémentation prend en charge le comportement « start() ».

Figure 7 Exemple de polymorphisme
2.5.3.3 Pure Fabrication

2.5.3.3.1 Théorie
Le pattern Pure Fabrication ne représente pas le modèle du domaine : c’est une forme
d’abstraction pour effectuer des traitements dans le seul but de rendre le système plus cohésif et
de limiter le couplage. A contrario, le pattern Expert n’est pas un pattern Pure Fabrication car il
représente un objet métier. Plus simplement ce sont des créations de l’esprit qui n’existent pas
dans le modèle du domaine car ils ne représentent aucune donnée comme par exemple un client
ou une facture.
La classe suivante cumule trop de responsabilités : elle est donc faiblement cohésive. En effet les
notions de persistance exprimées par les méthodes loadCustomer() et saveCustomer()
affaiblissent la cohésion de la classe.
Figure 8 Classe faiblement cohésive
Il est préférable dans ce cas d’utiliser, par exemple, la délégation de ces responsabilités à une
autre classe.
Figure 9 Délégation de responsabilité

2.5.3.4 Indirection
2.5.3.4.1 Théorie
L’indirection intervient lorsque l’on veut éviter un couplage entre deux Experts. Dans ce cas un
objet servira d’intermédiaire. D’ailleurs beaucoup de Pure Fabrication sont crées pour des besoins
d’indirection.
Prenons l’exemple de la classe Vector qui propose, pour énumérer ses éléments, une Enumeration
(ancêtre de l’Iterator). Notre client souhaite manipuler cette liste mais sans vouloir de couplage
avec cette Enumeration. Dans ce cas de figure il utilise un Adapter qui propose une interface
Iterator pour le client, tout en manipulant (en interne) une Enumeration.
Figure 10 L'Adapter reduit le couplage
2.5.3.5 Law of Demeter

2.5.3.5.1 Théorie
Le pattern Law of Demeter (ou protection des variations) tente de limiter l’effort dû à l’évolution
d’un système. Il consiste à utiliser uniquement des dépendances directes, c'est-à-dire des
dépendances envers des composants qui rendent un service, et aucune dépendance indirecte,
c'est-à-dire une dépendance envers un composant permettant d'obtenir la référence sur un
composant rendant un service. Les parties jugées modulables ou susceptibles d’évoluer doivent
être isolées.
Il existe plusieurs moyens à la disposition du concepteur pour rendre un système moins sensible
aux variations :
Externalisation de certaines valeurs dans des fichiers de propriétés.

Une conception par interfaces (JDBC, JAXB, JNDI, …).
Une communication par messages standards : l’émetteur et le récepteur ne se
connaissent pas (techniquement parlant).
« Don’t talk to strangers » : éviter les dépendances non nécessaires avec des systèmes
sans en avoir réellement l’utilité.
D’ailleurs beaucoup de designs patterns et de principes de programmation vont dans ce sens.

C’est le cas de l’encapsulation où les données et les traitements sont protégés de l’environnement
extérieur et où les éléments extérieurs ne sont pas affectés par les changements internes de la
classe.

2.6 Design principles

2.6.1Présentation
Les « design principles » sont 10 grands principes de conception répartis en 3 groupes :
Gestion des évolutions et des dépendances entre classes.

Organisation de l’application en modules.
Gestion de la stabilité de l’application.
En appliquant ces principes, ont doit arriver à un programme robuste et facilement modifiable et
ce sans y introduire d’erreurs.
2.6.2Gestion des évolutions et des dépendances entre classes

2.6.2.1 Open/Closed principle
2.6.2.1.1 Théorie
Le principe d’ouverture/fermeture tente de limiter les impacts (et donc les coûts) liées aux
changements. Tout module doit être ouvert aux extensions et fermé aux modifications. Le module
peut donc être étendu pour proposer des comportements n’existant pas lors de sa conception
mais les nouvelles extensions ne doivent pas altérer le code existant (Cf. pattern Strategy du
GOF). Attention cependant à ne pas exagérer et ne pas mettre trop facilement des points
d’ouverture dans votre application afin de ne pas injecter une complexité inutile. Il convient
d’identifier les futurs points d’ouverture en s’inspirant des besoins pressentis par le développeur ou
des changements multiples constatés durant le développement.
L’abstraction par utilisation d’interface est la solution la mieux adaptée en java pour limiter les
impacts des nouvelles fonctionnalités.
Figure 11 Limitation de la variation logicielle par utilisation de l'héritage
Dans ce cas de figure si nous souhaitons ajouter un comportement (Boat), il suffit d’ajouter une
classe dérivant de l’interface Vehicule. Les classes existantes ne sont pas modifiées et un
comportement nouveau est supporté.
Ce motif s’applique naturellement si certains principes de bon sens sont respectés :

- Les variables sont privées : des variables publiques non justifiées (autre que final) sont plutôt
le signe d’une mauvaise conception.
- Les variables ne doivent pas être globales : elles maintiennent inutilement des références et
alourdissent le système.
L’utilisation du mot clé instanceof est à proscrire au niveau de l’abstraction. En effet si l’on
souhaite ajouter un nouveau comportement ou une nouvelle fonctionnalité, il faudra modifier la
section de code de l’abstraction (ou du client) qui adopte un comportement différent (modification
d’une fonctionnalité existante) en fonction de l’implémentation.

2.6.2.2 Liskov substitution principle

2.6.2.2.1 Théorie
Le principe de substitution de Liskov (ou principe des 100%) part de l’hypothèse que le client doit
pouvoir utiliser des objets dérivés sans s’en apercevoir et sans avoir à changer son comportement
en fonction de l’implémentation. A tout moment une classe peut se substituer à une autre pour
autant que ces deux classes implémentent la même interface. Ce principe est important car bon
nombre d’héritages sont fait par commodité et sans réelle existence d’une nécessité d’abstraction.
D’ailleurs, il prend à contre pied un autre mauvais principe (anti pattern dirons nous) qui veut que
l’héritage serve à factoriser du code : les puristes lui préféreront la délégation. Dans le cas où une
classe ne se substituerait pas parfaitement à une autre, il y a un problème de conception.
Dans cet exemple, chaque implémentation de Vehicule peut prendre la place d’une autre sans que
le client puisse (et doive) s’en apercevoir.
Figure 12 Substitution possible entre les différentes implémentations
2.6.2.3 Dependency inversion principle

2.6.2.3.1 Théorie
Le principe d’inversion de dépendance part du précepte que la forte dépendance entre les couches
d’une application, nuit à sa réutilisation et à son évolution. Par exemple une couche IHM doit
connaître la couche métier pour pouvoir l’utiliser. La couche IHM est écrite pour cette couche
métier et ne peut être réutilisée autrement. Pour éviter ce couplage, les modules de haut niveau
ne doivent pas connaître les modules de bas niveau. Ils doivent plutôt dépendre d’abstractions. Le
module de haut niveau s’inscrit au module de bas niveau et écoute ses évènements (on retrouve
ici les fondements de l’injection de code). Cette approche permet aussi de faire apparaître
clairement les messages entre les objets et donc de facilement les normaliser.
Figure 13 Un couplage fort nuit à la réutilisation

L’utilisation d’une abstraction et d’une inversion des dépendances réduit le couplage et facilite la
réutilisation. La couche métier OrderBusiness (ou modèle) ne connaît que l’interface
OrderInterface (implémenté par OrderAction) vers laquelle elle envoie les évènements systèmes.
Figure 14 Réutilisation plus aisé
Aujourd’hui des containers légers comme Spring ou HiveMind offre une approche similaire. Les
services sont définis par une interface et une implémentation. Le container instancie
l’implémentation correspondante. Cette approche est intéressante en plusieurs points :
Couplage faible : seul les interfaces sont connus.

Principe d’ouverture/fermeture respecté.
Globalement l’application est moins sensible à la variation.
2.6.2.4 Interface segregation principle

2.6.2.4.1 Théorie
Il arrive que certaines classes remplissent plusieurs rôles au sein d’un système. Ce type de classe
expose tous ses services à chaque client et ne facilite pas la compréhension. De plus chaque
modification de la classe impacte potentiellement tous les clients. Ce pattern propose donc de
limiter la taille de la classe en répartissant les méthodes dans plusieurs classes (regroupement
technique ou fonctionnel par exemple).
Lorsqu’un service propose trop de fonctionnalités…
Figure 15 Trop de fonctionnalités proposées…
…il convient de répartir les services dans plusieurs classes.

Figure 16 Répartition plus homogène
2.6.3Organisation de l’application en modules

2.6.3.1 Reuse/Release equivalence principle
2.6.3.1.1 Théorie
Le pattern d’équivalence livraison/réutilisation propose d’avoir une approche modulaire de
l’application. Chaque sous-système est considéré comme une application (ou un Framework), et
développé et maintenu par un tiers. Il doit être utilisé tels quel, sans avoir à en comprendre les
mécanismes internes.
Le monde java avec les spécifications du JCP (Java Community Process) ainsi que les différents
Frameworks existants se prêtent bien à cette approche (Hibernate, Spring, Struts, etc…).
Figure 17 Utilisation du pattern DAO
Plutôt que de réécrire un Framework de persistance avec un pattern type DAO, utilisez un outil
d’ORM (Object Relational Mapping).

Figure 18 Utilisation d'un ORM

L’approche la plus professionnelle est d’utiliser les 2 concepts : une DAO pour masquer
l’implémentation (Hibernate par exemple) et l’utilisation d’une session Hibernate dans une
implémentation dédié (HibernateDao). Une factory prend la responsabilité de la création de la
bonne implémentation (décrite dans un fichier de propriétés par exemple).
Figure 19 Utilisation conjointe : ORM + DAO
2.6.3.2 Common reuse principle

2.6.3.2.1 Théorie
Le pattern de réutilisation commune propose de rassembler dans le même package, les classes
susceptibles d’être réutilisées conjointement. Il est important de rassembler ensemble des classes
ayant des rapports de dépendances les unes avec les autres, inutile en effet de mettre ensemble
des classes réutilisables mais ne couvrant pas le même domaine technique ou fonctionnel.
Imaginons un système de persistance de type DAO. Il sera nécessaire de posséder des classes
d’outils dédiées, par exemple, à la gestion de la connexion, de la transaction ou du cache. Toutes
ces classes devront être localisées dans le même package et distribuées ensemble.
2.6.3.3 Common closure principle

2.6.3.3.1 Théorie
Le principe de fermeture commune stipule que les classes qui seront impactées par un même
changement soient regroupées dans un même package.

2.6.4Gestion de la stabilité de l’application

2.6.4.1 Acyclic dependencies principle
2.6.4.1.1 Théorie
Le principe de dépendances acycliques repose sur la répartition des classes en packages pour
limiter la propagation des changements au sein de l’application. La propagation des changements
étant guidée par les dépendances entre packages, l’organisation de ces dépendances est un
élément fondamental de l’architecture. Pour pourvoir gérer ces changements, il convient de ne pas
introduire de dépendance cyclique dans les packages et de regrouper les classes dépendantes
dans le même package.
Dans ce cas de figure les dépendances sont cycliques, ce qui est un signe de mauvaise conception.
Figure 20 Dépendance cyclique
Pour contourner un besoin de référence cyclique, utilisez le principe d’inversion des dépendances.
2.6.4.2 Stable dependencies principle

2.6.4.2.1 Théorie
Le principe de relation de dépendance stable stipule qu’un package doit dépendre d’un package
plus stable que lui. Globalement ce principe permet de stabiliser l’application. Le développeur
apportera donc encore plus de soin à un module si celui ci est fortement utilisé par les autres.
Plusieurs critères permettent de définir le niveau de stabilité d’un module :
Plus les dépendances de ce module vers d’autres modules sont élevées, plus il est
susceptible d’être impacté par un changement et donc moins il est considéré comme
stable.
Plus il existe des relations vers ce module et plus il est considéré comme stable.
Dans ce cas de figure, on admet que la stabilité du composant doit être et sera (par force)
maximale.

Figure 21 Stabilité maximale
Par contre, on admet ici que la stabilité du composant est minimale puisque chaque changement
d’un des composants peut l’affecter ou le déstabiliser.
Figure 22 Stabilité minimale
2.6.4.3 Stable abstractions principle

2.6.4.3.1 Théorie
Le principe de stabilité des abstractions énonce que les packages les plus abstraits doivent être les
plus stables et les plus concrets les moins stables. Le degré de stabilité d’un package doit
correspondre à son degré d’abstraction.
Dans une application, les règles métiers seront plus stables que les objets techniques qu’ils
utilisent (EJB, Log, etc.) : En effet ceux-ci étant plus concrets, ils sont plus sensibles aux
évolutions.
2.6.5Conclusion
Les principes énoncés ci-dessus doivent vous permettre d’obtenir une application extensible,
robuste et réutilisable. Contrairement aux design patterns, ce ne sont que des principes et non
une recette directement applicable sur du code. Elle on toutefois l’intérêt de définir un cadre et
fixant de fait certaines limites.

2.7 Gang Of Four [GOF]

2.7.1Présentation
Le GOF propose 23 patterns avec une classification en 3 catégories :
Création : propose des modèles pour faciliter ou rationaliser la création de classes. Ils
permettent de faire la différence entre la création et le montage des objets et plus
globalement d’abstraire le mécanisme d’instanciation.
Structure : Ces patterns proposent aussi bien des modèles d’assemblages que
d’adaptation. Ce sont des patterns adaptés aux problèmes courants (structures de
données, …).
Comportement : propose des modèles qui réagissent à leur environnement en adoptant

des comportements spécifiques différents au cours de leur cycle de vie.
Note : Ce paragraphe n’a pas pour vocation de proposer un cours complet sur les Design patterns
du GOF : pour de plus amples renseignements, se reporter au livre de référence « Design Patterns
Elements of Reusable Object-Oriented Software ».
Chaque motif est noté de 1 à 5 en fonction de son intérêt.
2.7.2Patterns de création
2.7.2.1 Abstract Factory
2.7.2.1.1 Théorie
2.7.2.1.1.1 Présentation
Une fabrique abstraite délocalise la responsabilité de la création d’un objet. Plutôt que de confier
cette responsabilité au constructeur de l’objet, un objet dédié (la fabrique) la prend en charge. On
peut alors facilement utiliser des fabriques différentes pour le même type d’objet. Elle fournit donc
une interface pour créer des objets apparentés sans avoir la nécessité de spécifier leur classe
concrète.
2.7.2.1.1.2 UML
Figure 23 UML Théorique Abstract Factory
Dans cet exemple, chaque Factory fabrique un seul objet (PlaneFactory fabrique des Plane et
TruckFactory des Truck). L’intérêt est de pouvoir les manipuler en utilisant l’interface Factory : le
processus de création est donc normalisé. A noter que si l’on veut s’abstraire du choix de la
Factory on peut utiliser une Factory de Factory.
2.7.2.1.2.2 UML
Figure 24 UML implémentation Abstract Factory
Correspondance diagramme
théorique implémentation
AbstractFactory Factory
ConcreteFactory TruckFactory,
PlaneFactory
AbstractProduct Vehicule
AbstractProductImpl Truck, Plane
2.7.2.1.2.3 Utilisation
Factory pFactory = new PlaneFactory();

Vehicule vehicule = pFactory.build();
//code...
2.7.2.2 Builder

2.7.2.2.1 Théorie
Bien que souvent confondu avec le pattern Abstract Factory, le Builder est une approche différente
de la construction d’objets. En effet, outre le fait qu’il construit l’objet, il définit la façon de le
construire (on peut presque parler de configuration). On l’utilise aussi dans le cas où l’algorithme
de création et la méthode d’assemblage doivent être découplés de l’objet.
2.7.2.2.1.2 UML
Figure 25 UML théorique Builder

Ici le Director prend la responsabilité de l’ordre de montage de l’A380, alors que l’A380Builder
conserve la responsabilité de la construction des différentes parties.
2.7.2.2.2.2 UML
Figure 26 UML implémentation Builder
Product Plane
ConcreteBuilderProduct A380
ConcreteBuilder A380Builder
Builder PlaneBuilder
Director Director
A380Builder builder = new A380Builder();

new Director(builder).build();
Plane product = builder.getResult();
2.7.2.3 Factory Method

2.7.2.3.1 Théorie
La Factory Method est une variante de l’Abstract Factory. En effet, plutôt que de laisser au choix
du client l’instanciation de la classe concrète de construction, c’est la classe concrète qui en prend
la responsabilité.

2.7.2.3.1.2 UML
Figure 27 UML théorique Factory Method
Contrairement à l’Abstract Factory, c’est le client (AbstractCreator) qui prend la responsabilité de
la création de l’objet via sa méthode factoryMethod().
2.7.2.3.2.2 UML
Figure 28 UML implémentation Factory Method
AbstractProduct Product
ConcreteProduct Truck
AbstractCreator AbstractCreator
ConcreteCreator TruckCreator
Cf. méthode sampleUse().

2.7.2.4 Prototype

2.7.2.4.1 Théorie
Le prototype offre une autre approche quant à la création d’objet. Le principe de Factory est
intéressant, mais pèche par la création d’autant de Factory concrètes qu’il existe d’objets concrets.
Le pattern Prototype donne à l’objet concret la responsabilité de sa fabrication par une méthode
de clonage.
2.7.2.4.1.2 UML
Figure 29 UML théorique Prototype
Dans notre exemple, la classe Plane et Truck ont la capacité, via la méthode clone(), de se
dupliquer. On remarque une forte similitude avec java qui propose, via l’objet « Object »,
l’interface clone().
2.7.2.4.2.2 UML
Figure 30 UML implémentation Prototype
Prototype Prototype
ConcretePrototype Plane, Truck
//code...
Prototype otherPlane = plane.clone();

//code...
2.7.2.5 Singleton

2.7.2.5.1 Théorie
Il est parfois nécessaire de n’avoir qu’une seule instance d’une classe dans un système : c’est le
cas lorsqu’un seul objet est nécessaire pour coordonner un ensemble. Le pattern Singleton
propose un motif pour contrôler la création de l’instance. Cette responsabilité est attribuée à
l’objet concerné pour éviter un phénomène d’instanciation multiple. A noter que le pattern
singleton n’est pas nécessairement limitatif à une seule instance : on peut parfaitement l’utiliser
pour en contrôler plusieurs comme un pool d’objet.
2.7.2.5.1.2 UML
Figure 31 UML théorique Singleton
Dans cet exemple il suffit d’utiliser la méthode statique getInstance() pour obtenir une poignée sur
l’objet unique. L’instance retournée sera systématiquement la même.
2.7.2.5.2.2 UML
Figure 32 UML implémentation Singleton
Singleton Singleton
Singleton single = Singleton.getInstance();

2.7.3Patterns de structure
2.7.3.1 Adapter
2.7.3.1.1 Théorie
Le pattern Adapter permet de faire fonctionner un objet avec une interface qu’il n’implémente pas
habituellement. Ce motif est particulièrement pratique si vous ne souhaitez pas dépendre d’une
implémentation en particulier ou si vous souhaitez l'accommoder. L’adapter fera le lien entre les
méthodes de la nouvelle interface vers l’ancienne.
2.7.3.1.1.2 UML
Figure 33 UML théorique Factory Adapter
La version proposée est à base de délégation puisque java ne supporte pas l’héritage multiple.
Dans cet exemple, nous adaptons un objet de type Enumeration pour qu’il supporte l’interface
Iterator. L’utilisation pour le client est transparente puisqu’il utilisera une Enumeration comme un
Iterator.
2.7.3.1.2.2 UML
Figure 34 UML Implémentation Adapter

Target Iterator
Adapter IteratorEnumerationAdapter
Adaptee Enumeration
StringTokenizer tokenize = new StringTokenizer("java c'est bien");
for (Iterator iter = new IteratorEnumerationAdapter(tokenize); iter.hasNext();) {

String element = (String) iter.next();
System.out.println(element);
}
2.7.3.2 Bridge

2.7.3.2.1 Théorie
Le bridge permet de découpler une abstraction de son implémentation pour les rendre
indépendantes des évolutions. On évite un lien permanent entre l’abstraction et l’implémentation,
ce qui permet à chacun d’évoluer indépendamment. Au final les modifications d’implémentations
n’entraînent pas de recompilation de l’abstraction.
2.7.3.2.1.2 UML
Figure 35 UML théorique Bridge
Dans notre exemple nous déléguons la gestion des données d’un groupe de client à un
Implementor. L’abstraction du groupe de client propose des méthodes pour naviguer d’un client à
un autre. Enfin pour notre exemple nous utilisons une gestion des données en mémoire. Au
passage on s’aperçoit qu’il est très facile de proposer une autre implémentation (FileData ou
DBData par exemple) sans qu’il soit nécessaire de recompiler l’abstraction.

2.7.3.2.2.2 UML
Figure 36 UML implémentation Bridge
Abstraction AbstractCustomer
RefinedAbstraction Customers
Implementor DataObject
ConcreteImplementor InMemoryData
AbstractCustomers ab = new Customers("bons clients");
ab.setImplementor(new InMemoryData());
ab.add("claude durillon");
2.7.3.3 Composite

2.7.3.3.1 Théorie
Ce pattern s’adapte parfaitement à l’utilisation et à la manipulation d’objets complexes (structure
par association, arborescence, …) dont la profondeur n’est pas connue. Il propose une interface
simplifiée pour la manipulation d’objets uniques ou d’objets composés du même type.

2.7.3.3.1.2 UML
Figure 37 UML théorique Composite
Dans notre exemple, la classe Product contient une liste de ses enfants eux-mêmes de type
Product. Cette arborescence représente la notion de « est composé de… ». La manipulation de ce
graphe complexe se fait depuis le ProductComposite pour simplifier les opérations.
2.7.3.3.2.2 UML
Figure 38 UML implémentation Composite
Component, Leaf Product
Composite ProductComposite
Product pizza = new Product("1245789456124", "pizza 4 fromages");
Product pate = new Product("1245789446124", "pate à pizza");

Product farine = new Product("1245789446127", "farine");

Product eau = new Product("1245781446127", "eau");
Product fromage = new Product("1745789446127", "fromage");

//crée la pizza
ProductComposite composite = new ProductComposite(pizza);
//ajoute la pâte
composite.addProduct(pate, pizza.getId());
//la pâte est constituée d'eau et de farine
composite.addProduct(farine, pate.getId());
composite.addProduct(eau, pate.getId());
//enfin on ajoute le fromage
composite.addProduct(fromage, pizza.getId());
//en fait nan pas de fromage : trop gras

composite.removeProduct(fromage.getId());
2.7.3.4 Decorator

2.7.3.4.1 Théorie
Le motif Decorator permet d’accrocher dynamiquement des responsabilités à un objet. Il remplace
le principe d’héritage en offrant une méthode plus souple. On peut aussi l’utiliser si la classe ne
peut être héritée : c’est le cas si la classe utilise le modificateur final.
2.7.3.4.1.2 UML
Figure 39 UML théorique Decorator
2.7.3.4.2.1 Description
Dans notre exemple, nous allons ajouter une responsabilité sur la classe LibraryItem : les
instances de cette classe auront la capacité d’être empruntées par des clients. Par le truchement
de l’héritage, ses classes filles, en bénéficieront aussi. La méthode display() est surchargée par la
classe Borrowable pour afficher les informations des emprunteurs en cours : c’est dans cette
méthode que les nouvelles responsabilités sont ajoutées.

2.7.3.4.2.2 UML
Figure 40 UML implémentation Decorator
Component LibraryItem
ConcreteComponent Book, Video
Decorator Decorator
ConcreteDecorator Borrowable
Book book = new Book("Michael MARSHALL", "Le sang des anges", 10);
book.display();
Video video = new Video("Jacques TATI", "Mon oncle", 200 ,5);

video.display();
Borrowable borrowVideo = new Borrowable(video);

borrowVideo.borrowItem("Mr Dupont");
borrowVideo.borrowItem("Mr Durand");
//invocation des responsabilités supplémentaires
borrowVideo.display();
2.7.3.5 Facade

2.7.3.5.1 Théorie
Le pattern Facade fournit un point d’entrée unique et une interface simple à un système
complexe. Il s’inscrit dans un principe de découpage en couches et le risque d’un couplage fort
avec les classes internes d’une API est réduit. On peut le comparer à un tableau de bord d’un
véhicule : vous ne voyez et ne pouvez modifier que ce qui est nécessaire (essuie-glace,
clignotants) et le fait qu’il existe des pistons et des bielles dans le moteur ne vous concerne pas.

2.7.3.5.1.2 UML
Figure 41 UML théorique Facade
2.7.3.5.2.1 Description
Dans cet exemple, notre façade est matérialisée par la classe Compiler. Elle est le point d’entrée
unique à notre système de compilation.
2.7.3.5.2.2 UML
Figure 42 UML implémentation Facade
Facade Compiler
Subsystem CodeGenerator, Scanner,
Parser
5 Compiler compiler = new Compiler();
6 compiler.compile();
2.7.3.6 FlyWeight

2.7.3.6.1 Théorie
Le motif FlyWeight propose une technique de partage permettant la mise en œuvre d’une grande
quantité d’objet de granularité fine. Ce pattern s’applique particulièrement bien si l’état des objets
peut être externalisé, si le stockage des éléments coûte cher et enfin si les objets n’ont pas
d’identifiant (c’est le type de la classe qui identifie l’objet et non un de ses attributs). Le Pattern
FlyWeight propose le partage d’objet mais ne l’impose pas.

2.7.3.6.1.2 UML
Figure 43 UML théorique FlyWeight
Prenons un éditeur de texte pour notre exemple. Si nous raisonnons « pure objet », nous pensons
de la manière suivante : pour chaque caractère de chaque ligne et de chaque page, j’ai un objet
de type caractère. L’idée peut être intéressante mais on se rend vite compte que le nombre des
objets peut rapidement « exploser » pour des documents de taille importante. Le motif FlyWeight
permet d’externaliser certaines données : par exemple la largeur et la hauteur en point, le code du
caractère ne varient jamais. Par contre remis dans le contexte de la page, il est nécessaire de
connaître en plus la position ligne/colonne, la police employée, etc… Ce pattern fait donc le
distinguo entre les données intrinsèques (Position ligne/colonne, etc.) et externalisables (Code
caractère, etc.).
2.7.3.6.2.2 UML

Figure 44 UML implémentation FlyWeight
Flyweight GraphicalItem
ConcreteFlyweight Character, CharacterA, CharacterB,
CharacterZ
Unshared Row
ConcreteFlyweight
FlyweightContext Context, PageContext
FlyweightFactory GraphicalItemFactory
GraphicalItemFactory factory = new GraphicalItemFactory();
/*String line1 = "my flowers are beautiful";

String line2 = "my taylor is rich";*/
String line1 = "ABBBZZZABBZ";

String line2 = "ABABABAAAAABBZ";
Row row1 = (Row) factory.getRow(line1);

Row row2 = (Row) factory.getRow(line2);
//crée le context
PageContext context = new PageContext();
//positionne la fonte sur la 1ere ligne pour le caractère de 3 à 10
context.setFont("Arial", 1, 3 , 10);
//parcours la 1ere ligne

for (char c : row1.charArray()) {
GraphicalItem character = factory.getCharacter(c);
character.display(context);
context.next();
}
context.nextLine();
for (char c : row2.charArray()) {
GraphicalItem character = factory.getCharacter(c);
character.display(context);

context.next();
}
2.7.3.7 Proxy

2.7.3.7.1 Théorie
Le Proxy a pour fonction de se positionner entre un objet et son client. Il permet de référencer un
objet autrement qu’avec une poignée. Plusieurs Proxy existent en fonction de leur finalité
technique. On utilisera un Remote Proxy pour cacher toute la couche d’instanciation distante, un
Protection Proxy pour gérer l’authentification, un Lazy Proxy pour gérer l’instanciation d’un objet à
la demande, etc… Attention à ne pas le confondre avec une Facade ou un Adapter.
2.7.3.7.1.2 UML
Figure 45 UML théorique Proxy
Dans notre exemple, nous utilisons un Proxy pour manipuler un objet image. Le principal problème
est que l’image peut ne pas avoir terminé son chargement et les méthodes appelées risquent de
provoquer une exception. Le Proxy va donc mettre en attente les appels de méthodes, tant que
l’image n’est pas chargée. Une fois celle ci téléchargée, les méthodes s’exécutent. L’utilisateur du
Proxy subira un temps de latence lors du premier appel.
2.7.3.7.2.2 UML
Figure 46 UML implémentation Proxy

Subject Graphic
Proxy ImageProxy
RealSubject Image
//normalement le client ne doit jamais écrire ce qui suit
//c'est plutôt le rôle d'une factory
ImageProxy proxy = new ImageProxy(new Image());
proxy.draw();
2.7.4Patterns de comportement
2.7.4.1 Chain of Responsability
2.7.4.1.1 Théorie
Ce pattern propose de découpler l’émetteur d’une requête par rapport aux récepteurs potentiels.
La requête traverse la chaîne des récepteurs jusqu'à ce qu’un objet la traite. Le couplage est
fortement réduit et l’attribution des responsabilités est plus souple car des récepteurs peuvent être
créés ou retirés dynamiquement. Il reste un risque cependant qu’aucun des récepteurs ne
réponde à la requête.
2.7.4.1.1.2 UML
Figure 47 UML théorique Chain of Responsability
Dans cet exemple, des employés vont prendre des décisions sur un projet. Chaque participant
inscrit va recevoir le projet jusqu'à ce qu’il soit traité. On peut noter que la gestion de la liste
(permutation, suppression, etc...) n’est pas aisée.

2.7.4.1.2.2 UML
Figure 48 UML implémentation Chain of Responsability
Handler Approver
ConcreteHandler Employee
Employee director = new Employee("Director");
Employee vicePresident = new Employee("vicePresident");
Employee president = new Employee("president");
director.setSuccessor(vicePresident);
vicePresident.setSuccessor(president);
//on peut faire démarrer la requête depuis n'importe quel employé

Project project = new Project(1000, "Projet qui tue");
director.handleRequest(project);
2.7.4.2 Command

2.7.4.2.1 Théorie
Propose de supprimer le couplage entre l’objet qui invoque une opération et celui qui la réalise. Il
fonctionne comme le motif Bridge à la différence près qu’il s’occupe des traitements et non des
données. Au final, il permet de manipuler les traitements comme des objets et de pouvoir les
défaire à la demande.

2.7.4.2.1.2 UML
Figure 49 UML théorique Command
Dans notre exemple, la classe User est le point d’entrée du service : elle enregistre les
commandes et permet de les défaire sur plusieurs niveaux. La classe CalculatorCommand a la
responsabilité pour faire et défaire une commande à l’aide du Calculator.
2.7.4.2.2.2 UML
Figure 50 UML implémentation Command
Invoker User
Command Command
ConcreteCommand CalculatorCommand
Receiver Calculator
User user = new User();
user.compute('+', 100);
user.compute('-', 50);
user.compute('*', 10);
user.compute('/', 2);
// annule 4 commandes

user.undo(4);
// refait 3 commandes
user.redo(3);
2.7.4.3 Interpreter

2.7.4.3.1 Théorie
Définit une représentation pour une grammaire ainsi qu’un interpréteur pour cette grammaire. Il
facilite la création, la modification et l’extension de cette grammaire. Pratique pour une grammaire
simple, ce motif peut rapidement devenir complexe à maintenir à cause du nombre élevé de
classes. Enfin, les performances générales de ce pattern sont souvent médiocres.
2.7.4.3.1.2 UML
Figure 51 UML théorique Interpreter
L’exemple suivant propose un interpréteur pour des codes romains.
2.7.4.3.2.2 UML
Figure 52 UML implémentation Interpreter

Context Context
AbstractExpression Expression
TerminalExpression ThousandExpression,
HundredExpression,
TenExpression,
OneExpression
NonTerminalExpression
String roman = "MCMXXVIII";
Context context = new Context(roman);
ArrayList<Expression> tree = new ArrayList<Expression>();

tree.add(new ThousandExpression());
tree.add(new HundredExpression());
tree.add(new TenExpression());
tree.add(new OneExpression());
for (Expression expression : tree) {

expression.interpret(context);
}
System.out.println(roman + "=" + context.getOutput());
2.7.4.4 Iterator

2.7.4.4.1 Théorie
Propose un accès séquentiel aux éléments d’un objet sans en exposer la structure interne. Ce
pattern est bien connu en java puisqu’il permet d’exposer le contenu d’une collection via la
méthode iterator(). Il offre une interface uniforme pour parcourir différentes structures.
2.7.4.4.1.2 UML
Figure 53 UML théorique Iterator
Dans l’exemple suivant nous itérons une collection.
2.7.4.4.2.2 UML

Figure 54 UML implémentation Iterator
Iterator Iterator
ConcreteIterator RealIterator
Agregate AbstractCollection
ConcreteAgregate Collection
//nous évitons d'utiliser java.util.Collection pour l'exemple
String[] strings = {"a","z","e","r","t","y"};
Collection collection = new Collection(strings);
//vide le contenu dans la sortie standard
for (Iterator iter = collection.iterator(); iter.hasNext();) {
String element = (String) iter.next();
System.out.println(element);
}
2.7.4.5 Mediator

2.7.4.5.1 Théorie
Le Mediator réduit le couplage entre plusieurs classes en les dispensant de se faire explicitement
référence : il prend en charge la manière dont les objets interagissent et de cette façon il
formalise la coopération entre objets.
2.7.4.5.1.2 UML
Figure 55 UML théorique Mediator

Dans notre exemple, nous utilisons un chat room pour le jeu Counter Strike. Chaque participant
envoie des messages aux personnes enregistrées.
2.7.4.5.2.2 UML
Figure 56 UML implémentation Mediator
Mediator AbstractChatroom
Colleague Participant
ConcreteMediator CounterStrikeChatRoom
ConcreateColleague Fighter
CounterStrikeChatroom chatRoom = new CounterStrikeChatroom();
Participant killer = new Fighter("killer");

Participant grenadier = new Fighter("grenadier");
Participant mechant = new Fighter("mechant");
chatRoom.register(killer);
chatRoom.register(grenadier);
chatRoom.register(mechant);
killer.send("yahooooo");
grenadier.send("gogogo");
mechant.send("no prisonner");
2.7.4.6 Memento

2.7.4.6.1 Théorie
Ce pattern propose de capturer et restaurer au besoin, l’état interne d’un objet et ce sans violer le
principe d’encapsulation. La sauvegarde et la restauration peuvent s’effectuer sur une partie ou
l’ensemble de l’objet.

2.7.4.6.1.2 UML
Figure 57 UML théorique Memento
Dans notre exemple, le Memento sauvegarde l’état du véhicule avec les options.
2.7.4.6.2.2 UML
Figure 58 UML implémentation Memento
Originator Car
Memento CarMemento
CareTaker CarMemory
//configuration du véhicule
Car car = new Car("Renault megane");
car.setAirConditionning(true);
car.setSlidingRoof(true);
//sauvegarde de la configuration
CarMemory mem = new CarMemory();
mem.setMemento(car.createMemento());
//continue à modifier
car.setAirConditionning(false);
//restore l'état de l'objet

car.restoreMemento(mem.getMemento());
2.7.4.7 Observer

2.7.4.7.1 Théorie
Définit une dépendance dynamique de type 1 à plusieurs, de façon telle que, quand un objet
change d’état, tous ceux qui en dépendent en soient notifiés. Il permet d’isoler la relation du Sujet

vers les observateurs : le sujet ne les connaît pas mais il peut les prévenir. Cependant il devient
difficile de mesurer les interdépendances, voire les références circulaires.
2.7.4.7.1.2 UML
Figure 59 UML théorique Observer
Dans notre exemple, 2 investisseurs écoutent le cours de l’action IBM. Chaque investisseur s’inscrit
par le biais de la méthode attach(). A noter que Java propose un système équivalent basé sur
java.util.Observer et java.util.Observable.
2.7.4.7.2.2 UML
Figure 60 UML implémentation Observer
Subject Stock
ConcreteSubject IBM
Observer Investor
ConcreteObserver Sorros, BerkShire
//crée les investisseurs
Sorros s = new Sorros("Sorros");
BerkShire b = new BerkShire("Berkshire");

//crée les Actions IBM et attache les investisseurs

IBM ibm = new IBM("IBM", 120.00d);
ibm.attach(s);
ibm.attach(b);
//le changement de prix de l'action notifie les investisseurs

ibm.setPrice(120.10d);
ibm.setPrice(130.20d);
2.7.4.8 State

2.7.4.8.1 Théorie
Le motif State permet à un objet de modifier son comportement quand son état change, donnant
ainsi l’impression que l’objet lui-même a été modifié. Ce pattern bien que peu répandu est
extrêmement puissant ; il évite les « switch » ou blocs d’instruction « if » à n’en plus finir.
Cependant la multiplication des états peut rendre la lecture complexe. Enfin le choix du
positionnement des états successifs est quelque peu éparpillé : il peut être souhaitable d’avoir une
classe ayant cette responsabilité.
2.7.4.8.1.2 UML
Figure 61 UML théorique State
Dans notre exemple, nous simulons l’état d’une banque. Une banque peut avoir aucune ou
plusieurs agences. Une banque a 3 états : UnInitialize (la banque n’a pas de nom), Initialize (la
banque a un nom mais pas d’agence) et HaveAgency (la banque a un nom et des agences).
2.7.4.8.2.2 UML

Figure 62 UML implémentation State
Context
State BankState
ConcreteState UnInitializeState,
InitializeState,
HaveAgencyState
Bank bank = new Bank(null);
// UnInitializeState
System.out.println(bank.getStateName());
bank.setName("BNP");
// InitializeState
Agency rennes = new Agency("Rennes");

Agency tours = new Agency("Tours");
bank.addAgency(rennes);
bank.addAgency(tours);
// HaveAgencyState
bank.removeAgency(rennes);
bank.removeAgency(tours);
// InitializeState
2.7.4.9 Strategy

2.7.4.9.1 Théorie
Le motif Strategy définie des familles d’algorithmes (répondant à la même interface), les rendant
interchangeables dynamiquement. Ils peuvent ainsi évoluer indépendamment des clients qui les
utilisent. Il fournit une alternative par l’héritage mais on peut toutefois craindre une prolifération
des classes.

2.7.4.9.1.2 UML
Figure 63 UML théorique Strategy
Notre exemple permet de compacter des fichiers en utilisant des algorithmes de compression
différents.
2.7.4.9.2.2 UML
Figure 64 UML implémentation Strategy
Strategy InflateStrategy
Context InflateContext
ConcreteStrategy ZipStrategy,
TarGunzipStrategy,
RarStrategy
//ajoute le fichier toto.txt dans le fichier zip toto.zip
InputStream in = new FileInputStream("c:\\toto.txt");
OutputStream out = new FileOutputStream("c:\\toto.zip");
InflateContext iContext = new InflateContext("toto.txt", in, out);

iContext.inflate();

2.7.4.10 Template Method

2.7.4.10.1 Théorie
Définit dans une opération, le squelette d’un algorithme avec ses parties invariantes, en déléguant
certaines étapes à des sous classes. Les sous-classes définissent certaines parties de l’algorithme.
Ce motif est, dans l’esprit, proche de la Factory Method mais se limite aux traitements et non aux
données. La classe représente l’algorithme, et les méthodes les éléments variants de cet
algorithme.
2.7.4.10.1.2 UML
Figure 65 UML théorique Template Method
Dans notre exemple, une partie de l’algorithme de choix de permutation d’élément pour un tri est
externalisé.
2.7.4.10.2.2 UML
Figure 66 UML implémentation Template Method
TemplateContext Sorter
Implementor DescSorter
Sorter sorter = new DescSorter();
int[] ints = {1,3,2};

for (int i = 0; i < ints.length; i++) {

System.out.print(ints[i]);
}
sorter.sort(ints);
System.out.println();
for (int i = 0; i < ints.length; i++) {
System.out.print(ints[i]);
}
2.7.4.11 Visitor

2.7.4.11.1 Théorie
Le motif Visitor permet à une classe externe de pouvoir parcourir les données d’un objet. Il nous
permet de définir de nouveaux traitements sur les données sans en affecter la classe propriétaire.
On peut ainsi en ajouter sans introduire de variation sur la classe portant les données.
2.7.4.11.1.2 UML
Figure 67 UML théorique Visitor
Dans notre exemple, nous utiliserons un Visitor pour parcourir un objet Bank et en extraire une
représentation textuelle (xml et csv). Chaque classe susceptible d’être visitée doit contenir une
méthode « accept(Visitor v) ». Le code de cette méthode exécute en retour l’instruction
« v.visit(this) ».
Figure 68 UML implémentation Visitor

2.7.4.11.2.2 UML
Visitor BankVisitor
ConcreteVisitor XMLBankVisitor,
CSVBankVisitor
Element Element
ConcreteElement Bank
//constitue les données
Bank bank = new Bank("BNP");
Agency rennes = new Agency("rennes");
Agency tours = new Agency("tours");
bank.addAgency(rennes);
bank.addAgency(tours);
//génére la version xml des données

BankVisitor xml = new XMLBankVisitor();
bank.accept(xml);
//génére la version csv des données

BankVisitor csv = new CSVBankVisitor();
bank.accept(csv);
2.8 Pattern JEE

On s’intéressera ici à l’utilisation de Patterns les plus communs au sein de Java Enterprise Edition
afin d’améliorer les performances, la fiabilité et la cohérence.
2.8.1Business Delegate
2.8.1.1 Problème
Au travers des appels directs au métier, le client n'optimise pas ou peu les accès aux objets à
travers le réseau. Cette non optimisation peut coûter cher en termes de performance.
Bien que proche du pattern Session Facade, le Business Delegate est différent : en effet il n'est
qu'une coquille vide qui se borne à router les appels vers l'objet distant : il ne fait pas d’agrégation
de services.
2.8.1.2 Solution
Le pattern Business Delegate à donc pour objectif de réduire le couplage entre le client et les
services métier. Il en cache l'implémentation technologique. Il agit comme une abstraction de la
partie métier. Ceci à plusieurs avantages :
Plusieurs clients de natures différentes peuvent accéder au métier.

Les services métier peuvent évoluer facilement en fonction des besoins.
Pour des besoins de performances, le Business Delegate peut exploiter des caches.
Du point de vue du client, la localisation des objets métiers est complètement transparente.
La reprise sur incident est gérée de manière centralisée (par exemple, si un service métier
distant ne répond pas, le Business Delegate peut décider d'attendre la disponibilité ou de
gérer une exception)
Les interfaces proposées au client sont plus simples et uniformes.

Figure 69 : Description du pattern Business Delegate
2.8.1.3 Implémentation
Ci-dessous un exemple de code appliquant le pattern Business Delegate à un EJB session. Le
constructeur par défaut instancie un objet distant. Dans le reste de la classe on retrouve toutes les
méthodes propres à l'objet distant. Si c'est un EJB session stateful, l'astuce est d'utiliser la
méthode finalise() pour effectuer un ejb.remove() afin de libérer la ressource.
public class MySessionBusinessDelegate {
// référence à un session distant

private MySession session;
public MySessionBusinessDelegate () throws ResourceException {

try {
MySessionHome home =(MySessionHome) ServiceLocator.getInstance().

getRemoteHome("MySession", MySessionHome.class;);
session = home.create();
} catch (ServiceLocatorException ex) {

throw new ResourceException(...);
} catch (CreateException ex) {
} catch (RemoteException ex) {
}
}
//exemple de méthode distante

public ResourceTO getResourceDetails() throws ResourceException {
try {
return session.getResourceDetails();
} catch (RemoteException ex) {

}
}
...
//pour les ejb stateful

protected void finalize() throws Throwable {
home.remove();
}
}
2.8.2Service Locator
2.8.2.1 Problème
Les spécifications J2EE offrent la possibilité d'interagir avec des composants orientés services tels
que les EJB, les composants JMS, etc. Pour les utiliser ils doivent soit être localisés (au travers
d'une opération de "lookup"), soit créés.
Pour rechercher ces composants, les applications J2EE utilisent JNDI pour pouvoir accéder à
différents services ou ressources. Les serveurs J2EE enregistrent ces ressources auprès d’un
annuaire JNDI de manière à ce que les clients puissent accéder à ces ressources depuis n’importe
quel point du réseau en invoquant le service d’annuaire. Ces ressources et ces services peuvent
être :
Des objets EJBHome

Des sources de données
Des ConnectionFactory JMS
Des topics ou queues JMS
etc …
Ainsi par exemple, les clients d’EJB doivent initialement récupérer l’objet EJBHome depuis
l’annuaire JNDI pour pouvoir invoquer les méthodes de l’EJB. Les clients JMS doivent récupérer la
ConnectionFactory, les topics et les queues pour manipuler les messages. Les clients JDBC doivent
récupérer l’objet DataSource pour obtenir une connexion à la base de données.
Tous ces clients doivent donc utiliser le protocole JNDI à chaque fois qu’ils ont besoin de l’une de
ces ressources. Or, le lookup JNDI est un processus coûteux car le client doit obtenir une
connexion réseau vers le service d’annuaire.
2.8.2.2 Solution
Le pattern Service Locator donne la responsabilité de la localisation des ressources à un objet
dédié.
Le Service Locator peut participer à la gestion du partage de charge. En effet, il peut être
développé de manière à chercher les services sur des machines physiquement différentes en cas
de surcharge.
Il peut servir à étendre les services de nommage JNDI en utilisant des caches et ce afin de limiter
les appels redondants à l’annuaire. Seule la première invocation est coûteuse : les fois suivantes,
c’est le cache qui est directement utilisé au lieu de faire un appel à l’annuaire.
Si on utilise ce pattern, le client n’a donc plus à appeler les services JNDI directement, il effectue
ces appels auprès du ServiceLocator qui se charge soit de faire le lookup JNDI ou bien de renvoyer
les objets depuis son cache ou alors de créer directement les objets.
Le client se trouve ainsi découplé du système d’obtention de l’objet. Par exemple l’obtention d’un
objet de service HiveMind nécessite une Registry. Dans notre cas, seul le ServiceLocator connaît la
Registry : si nous souhaitons changer de containeur d’objets, la variation se limitera uniquement
au ServiceLocator.
Figure 70 : Le Service Locator devient le point d’entrée pour obtenir des ressources

Ci-dessous un exemple possible d'implémentation du pattern Service Locator. La classe est un
singleton : c'est-à-dire qu'il n'existe qu'une seule instance dans une JVM. Une Map conserve les
homes déjà trouvées. L'utilisation s'effectue via la méthode getInstance() puis une des méthodes
dédiées à la recherche d'objets (getLocalHome(…), getRemoteHome(…)).
public class ServiceLocator {
private InitialContext initialContext;

private Map cache;
private static ServiceLocator _instance;
static {
try {
_instance = new ServiceLocator();
} catch (ServiceLocatorException se) {

System.err.println(se);
se.printStackTrace(System.err);
}
}
private ServiceLocator() throws ServiceLocatorException {

try {
initialContext = new InitialContext();

cache = Collections.synchronizedMap(new HashMap());
} catch (NamingException ne) {

throw new ServiceLocatorException(ne);
} catch (Exception e) {
throw new ServiceLocatorException(e);
}
}
static public ServiceLocator getInstance() {

return _instance;
}
public EJBLocalHome getLocalHome(String jndiHomeName)

throws ServiceLocatorException {
EJBLocalHome localHome = null;
try {
if (cache.containsKey(jndiHomeName)) {
localHome = (EJBLocalHome)cache.get(jndiHomeName);
} else {
localHome = (EJBLocalHome)initialContext.lookup(jndiHomeName);
cache.put(jndiHomeName, localHome);
}
} catch (NamingException nex) {

throw new ServiceLocatorException(nex);
} catch (Exception ex) {
throw new ServiceLocatorException(ex);
}
return localHome;
}
public EJBHome getRemoteHome(String jndiHomeName, Class homeClassName) throws ServiceLocatorException {

EJBHome remoteHome = null;
try {
if (cache.containsKey(jndiHomeName)) {
remoteHome =
(EJBHome) cache.get(jndiHomeName);
} else {
Object objref =
initialContext.lookup(jndiHomeName);
Object obj = PortableRemoteObject.
narrow(objref, homeClassName);
remoteHome = (EJBHome)obj;
cache.put(jndiHomeName, remoteHome);
}
} catch (NamingException nex) {
throw new ServiceLocatorException(nex);
} catch (Exception ex) {
throw new ServiceLocatorException(ex);
}
return remoteHome;
}
// implémenter ici les autres méthodes de lookup (datasource, hibernate factory,…)
...

2.8.3Session Facade
2.8.3.1 Problème
Les EJB encapsulent la logique métier et les données métier. Pour les utiliser, il faut connaître les
interfaces et être au fait de la complexité d'interaction entre tous ces objets.
Les clients d’EJB (applications swing, servlets, jsps, etc.) peuvent accéder à des EJB distants de
manière directe. A chaque appel d’un EJB, un transfert réseau est effectué entre le client et l’EJB.
Pour une requête d’un client, il arrive souvent que tout un ensemble d’EJB soit appelé. Si les
appels se font directement il en résulte un grand nombre d’appels à travers le protocole RMI/RMI-
IIOP. Ces transferts réseau à répétition peuvent rapidement devenir coûteux et dégrader
directement les performances générales d’une application.
Figure 71 : Nombre élévé de requêtes à travers le réseau
2.8.3.2 Solution
Le pattern Session Facade propose d’utiliser un EJB Session en tant que façade pour :
1. réduire le trafic réseau en :

encapsulant tous les appels afin finalement de ne faire qu’un appel distant.
gérant plus finement la granularité des données (seules les informations nécessaires sont
fournies au client du Session Facade).
2. découpler le client du métier en :
cachant la complexité d'interaction entre les différents composants métier.
évitant d'exposer les objets métier au client.
proposant un service uniforme permettant d'abstraire l'implémentation du métier
(améliore la granularité des traitements). Par exemple, au lieu d'effectuer un débit sur un
compte puis un crédit sur un autre, la façade peut proposer d'effectuer un virement.
3. centraliser la sécurité.
4. centraliser la gestion des transactions.

Figure 72 : Session Facade
Ici, le client ne fait qu’un seul appel à travers le réseau vers la Session Facade qui va agréger le
résultat des différents appels. De plus, dans ce cas, comme les EJB ne sont accédés que par la
façade, ils peuvent être déployés comme locaux ce qui optimise encore les appels entre la façade
et les EJB. Au total on réduit donc le trafic réseau, le nombre d’appels RMI et le temps d’appel des
EJB.
Ne pas confondre le pattern Service Facade avec le pattern Business Delegate. Le premier contient
du code métier alors que le second n'est qu'une coquille vide qui redirige les appels vers l'objet
distant. D'ailleurs un Service Facade ne devrait être utilisé que via son Business Delegate.
Le Session Facade est la plupart du temps implémenté via un Session Bean Stateless. Celui-ci
contient la logique métier et sait quels services ou objets métiers il devra interroger/utiliser pour
effectuer son travail.
2.8.4Message Facade / Service Activator

2.8.4.1 Problème
Les méthodes des EJB Session et Entité s’exécutent de manière synchrone. Ceci signifie que
l’appelant d’une méthode doit attendre qu’une valeur lui soit retournée. Dans certaines situations
telles qu’envoyer des centaines de mails ou lancer un Process en batch, le client n’a pas à se
soucier d’une quelconque valeur de retour.
Conserver un mode de fonctionnement synchrone pour ce type de besoin se révèle très coûteux,
car il m’est en attente l’ensemble de l’application et les utilisateurs associés à la commande.
Figure 73 : Exécution synchrone

2.8.4.2 Solution
Le pattern Message Facade permet d'éviter qu’un client n’ait à attendre une valeur de retour. Pour
cela, il est préférable d’utiliser des EJB Message asynchrones (Message Driven Beans). Dans ce
cas, le client peut continuer le cours de son exécution après avoir envoyé son message. La
communication est alors asynchrone et les traitements peuvent être parallélisés.
Figure 74 : Exécution asynchrone
Plusieurs solutions existent. La première est de proposer un frontal répliquant toutes les méthodes
du Business Delegate que l'on souhaite atteindre et qui utilisera JMS. Un EJB MDB en attente sur
la queue JMS appellera directement le Business Delegate. Deuxième solution : proposer un frontal
générique avec une méthode unique. Les paramètres de ce frontal seront la classe du Business
Delegate, le nom de la méthode, un tableau d'objets contenant les paramètres de la méthode.
La première solution est plus claire et simple à utiliser mais moins évolutive, la seconde, plus
complexe à utiliser, permet d'invoquer n'importe quel objet de manière asynchrone (attention
cependant : en cas d’échec, le processus appelant ne pourra être averti).
2.8.5Transfer Object / Value Object

2.8.5.1 Problème
Quand un client invoque une méthode distante, cette invocation est transformée en appel réseau,
puis résolue côté serveur et enfin la réponse est elle aussi envoyée à travers un appel réseau. Les
performances peuvent rapidement se dégrader si l’ensemble des attributs d’un objet distant sont
récupérés de la sorte. En effet, les appels aux méthodes au travers du réseau mettent en œuvre
tout un processus de sérialisation/dé sérialisation très coûteux.
Par exemple, si on souhaite récupérer des informations sur un objet, faire des appels consécutifs
tels que ceux-ci peut vite devenir très consommateur :

Figure 75 : Granularité fine des appels de méthodes
2.8.5.2 Solution
Le pattern Transfer Object permet d'éviter les appels répétitifs à travers le réseau en remplaçant
les méthodes invoquées en un objet comprenant tous les attributs désirés. On fera alors
uniquement transiter par le réseau l'objet contenant seulement les informations désirées.
Figure 76 : Granularité plus forte : une seule méthode invoquée
Dans ce cas, il n’y a qu’un seul appel à travers le réseau au lieu de plusieurs auparavant. L’objet
lui-même est transféré à travers le réseau au lieu de faire transiter ses attributs un à un.
L'implémentation de ce pattern est simple et sans surprise. Chaque méthode de session retourne
un Value Object. Les Values Objects sont eux de simples porteurs d'information sérialisables. Il
peut être intéressant d'implémenter Comparable afin de permettre par exemple des tris. En effet
les Values Objects étant la plupart du temps destinés à être affiché, il convient de pouvoir
facilement les ordonner.
Exemple de Value Object :
public class AccountVO implements Serializable, Comparable {
private String login;

private String password;
public AccountVO() {
login = null;
password = null;
}

public void setLogin(String login) {

this.login = login.toLowerCase();
}
public String getLogin() {

return login;
}
public void setPassword(String password){

this.password = password;
}
public String getPassword() {

return password;
}
public int compareTo(Object object) {

AccountVO accountValue = (AccountVO)object;
return getLogin().compareToIgnoreCase(accountValue.getLogin());
}
public boolean equals(Object object) {

if(!(object instanceof AccountVO)) {
return false;
} else {
AccountVO accountValue = (AccountVO)object;
return getID().equals(accountValue.getID());
}
}
public String toString() {

return login + "/" + password;
}
…
}
2.8.6Transfer Object Assembler / Value Object Assembler

2.8.6.1 Problème
Pour une seule requête, un client peut avoir besoin d’accéder à de multiples composants serveur
tels que des EJB Session et Entité. Dans cette situation, le client invoque de multiples composants
à travers le réseau ce qui à un impact direct sur les performances.
De plus, dans la plupart des cas, le client à besoin de reconstruire une structure à partir des brides
de données qu'il a pu récupérer. Nous nous retrouvons dans la même situation que le Transfert
Object mais à niveau de granularité plus forte.
Figure 77 La récupération des différentes brides d'informations encombre le réseau
2.8.6.2 Solution
Pour répondre à ce problème, le pattern Transfer Object Assembler propose la construction d'un
objet composite. Il assemble les différents Transfer Object récupérés auprès des différents
composants métier. Il renvoi l'objet composite au client après son assemblage et ne nécessite
qu’un appel réseau.

Figure 78 Le TransfertObjectComposite limite les appels
Proposer cette fonctionnalité au travers de Session Facade qui retournera, non pas un objet mais
un graphe de Value Objets constitués par assemblage de plusieurs Values Objects.
2.8.7Value List Handler

2.8.7.1 Problème
Les applications J2EE implémentent généralement des fonctionnalités de recherche qui ont à
parcourir une grande quantité de données. Si une application retourne énormément de données
en une seule fois au client, celui-ci devra attendre un long moment avant d’afficher une seule
donnée.
D'autre part, le client effectue souvent d'autres recherches sans parcourir l'intégralité des données
qu'il a déjà reçues ce qui fait que les données ont transitées pour rien à travers le réseau. Cela a
un impact direct sur les performances du serveur (réseau et mémoire). Si l'application utilise un
EJB Entity pour les données, les performances peuvent être catastrophiques.
Figure 79 L'utilisation du findAll sur un Entity dégrade fortement les performances
2.8.7.2 Solution
Le pattern Value List Handler permet de réduire ces fortes charges. Il accède directement à un
DAO plus performant qu'un EJB. Ce DAO lui renvoi une collection de Transfer Objects. Le Value
List Handler est une alternative au "finders" EJB pour des grosses requêtes.

Figure 80 Utilisation d'une Dao avec un mode page par page
Le Value List Handler accède directement aux données via une DAO (EJB Entity à proscrire). Il
permet de contrôler la recherche, de cacher les données si nécessaires. Il peut aussi retourner au
client un sous ensemble des données correspondant à ce qu'il a demandé (affichage page par
page).
2.8.8Data Access Object

2.8.8.1 Problème
Beaucoup d'applications ont besoin d'exploiter un système persistant de données. Pour cela, il
peut y avoir beaucoup de mécanismes différents mais surtout beaucoup de différences entre les
API utilisées pour accéder à ces différents systèmes de persistance.
Par exemple les données peuvent se trouver dans une base de données relationnelle, un annuaire
LDAP, des documents XML, un système propriétaire, etc. Ces différences fondamentales entre les
systèmes de stockage rendent le code de l'application très dépendant du code d'accès au système
de persistance.
2.8.8.2 Solution
Utiliser le pattern Data Access OBject (DAO) pour abstraire et encapsuler tous les accès aux
différentes sources de données. C'est la DAO qui gère la connexion et l'obtention des données de
la source. Le DAO n'expose que les interfaces simples permettant de manipuler les données en
cachant les mécanismes complexes liés aux différents systèmes de stockage. Si le système de
stockage évolue, c'est le DAO qui devra s'adapter tout en proposant toujours les mêmes interfaces
au client. Il est à noter que la DAO n’offre pas les mécanismes évolués (cache de premier niveau
et de second niveau, unicité d’objets, lazy loading) que propose des ORM tels que Hibernate ou
certaines implémentations de JDO.
Exemple typique d’une Dao supportant plusieurs systèmes d’ORM. La Factory prend la
responsabilité de créer la bonne implémentation (HibernateDao ou JpoxDao).

Figure 81 Dao proposant plusieurs implémentations
2.8.9Conclusion
Utiliser le Pattern ServiceLocator pour améliorer les performances d'accès aux services
distant (réduire le coût du lookup JNDI) et abstraire la technique d’obtention de la référence
du service.
Utiliser le Pattern SessionFacade pour empêcher les accès directs aux EJB et optimiser les
appels aux objets à travers le réseau.
Utiliser le Pattern MessageFacade/ServiceActivator pour l’exécution des méthodes au
temps d’exécution important et ne nécessitant pas de valeur de retour.
Utiliser le Pattern Transfer Object/Value Object pour diminuer le nombre d’invocations de
méthodes à travers le réseau.
Utiliser le Pattern TransferObjectAssembler/ValueObjectAssembler pour agréger les
informations dans le but d’éviter des appels réseau multiples.
Utiliser le Pattern ValueListHandler pour envoyer en mode « page par page », les données
au client.
Utiliser le pattern Data Access Object pour uniformiser la méthode d’accès à un ou plusieurs
espaces de persistance même différent technologiquement.

3 ANTI-PATTERNS
Ce chapitre s’attarde sur les erreurs de conception répandues et habituelles : les anti-patterns. On
les appels ainsi car ils apparaissent durant la phase de conception. Un anti-pattern est considéré
comme tel lorsqu’il produit plus de problèmes qu’il n’en résout.
3.1 Code source

3.1.1Code court
Certains codeurs estiment (à ce niveau ça devient de la compétition) que plus le code est
compact, meilleur sera le programme. Le code est compact, sans espace (ou le strict minimum) et
peu lisible (voir illisible). C’est une pratique répandue et sans grand intérêt : oubliez la, faites
simple et lisible.
3.1.2Optimisation
Sous prétexte d’optimiser le code, un développeur peut rendre un programme totalement illisible.
Dans la plupart des cas préférez la lisibilité à l’optimisation. Si l’optimisation fait partie des
contraintes du système, commentez copieusement votre code.
3.1.3Copier/Coller
Certainement responsable d’une grande partie des bugs applicatifs à ce jour. Problématique car le
contexte source et le contexte cible ne sont pas toujours les mêmes. Cette méthode va d’ailleurs
contre un principe essentiel de la conception objet : la réutilisation. A éviter donc.
3.1.4Variables
Les variables sont privées, des variables publics non justifiées sont plutôt le signe d’une mauvaise
conception : on y accède via des getters et de setters uniquement. Dans le même esprit les
variables globales dans des « Pure Abstraction (cf. GRASP)» ont rarement de raison d’être : elles
maintiennent inutilement des références et alourdissent le système.
3.1.5Concaténation de chaînes de caractères

Malgré ce que l’on pense, le code suivant n’est pas mauvais ; il est même optimum :
String s = "In memory-constrained situations" +
", you should pay close attention" +
" to the" +
" proliferation " +
"of"+
" strings";
En effet, le compilateur va optimiser l’expression en la transformant en une seule chaîne ou utiliser
un StringBuffer.
Par contre celui-ci est plus coûteux car le compilateur ne sait pas l’optimiser.
String s = "In memory-constrained situations";
s+= ", you should pay close attention";
s+= " to the";
s+= " proliferation ";
s+= "of";
s+= " strings";
3.1.6Cohérence du système
Le bloc finally est sous employé dans le code des méthodes. Pourtant il permet, même en cas
d’erreurs, de libérer proprement les ressources, laissant le système dans un état cohérent.

Dans cet exemple si la boucle while génère une erreur, les fermetures de resultset, statement et
connection seront compromises.
public void execute() throws IOException, DataException {

try {
// retrieve data from the database
Statement statement = connection.createStatement();
result = statement.executeQuery("SELECT subject, author, board from posts");
while (result.next()) {
subject.addElement(result.getString(SUBJECT_COLUMN));
author.addElement(result.getString(AUTHOR_COLUMN));
board.addElement(result.getString(BOARD_COLUMN));
}
result.close();
statement.close();
connection.close();
} catch (Throwable theException) {
theException.printStackTrace();
}
}
Il est préférable d’utiliser le bloc finally pour effectuer l’opération de libération des ressources.
public void execute() throws IOException, DataException {
try {
// retrieve data from the database
Statement statement = connection.createStatement();
result = statement.executeQuery("SELECT subject, author, board from posts");
while (result.next()) {
subject.addElement(result.getString(SUBJECT_COLUMN));
author.addElement(result.getString(AUTHOR_COLUMN));
board.addElement(result.getString(BOARD_COLUMN));
}
} catch (Throwable theException) {
theException.printStackTrace();
} finally {
result.close();
statement.close();
connection.close();
}
}
3.1.7Typage fort/faible
Lorsque vous déclarez et utilisez un type défini, il existe souvent une interface plus abstraite pour
le manipuler, facilitant les modifications sans remettre en cause fondamentalement l’algorithme.
Exemple avec la classe ArrayList qui hérite de List.
Le code suivant :
private ArrayList list = new ArrayList();
S’écrira plutôt :
private List list = new ArrayList();
En effet si nous souhaitons utiliser une LinkedList, le code de la classe qui utilise la variable « list »
reste inchangé, seule la déclaration change.
private List list = new LinkedList();

Préférez donc si possible un typage faible pour la déclaration de vos variables.
3.1.8Synchronized
Le mot clé synchronized permet de définir des sections critiques thread safe. Il est souvent utilisé
avec la déclaration de la méthode d’une classe
public synchronized void theMethod() {
Cette écriture est équivalente à

public void theMethod() {
synchronized (this) {
…
}
}
Plutôt que d’utiliser synchronized au niveau de la méthode, il est préférable de l’utiliser

uniquement sur la section de la méthode qui nécessite un accès thread safe. D’ailleurs, rien
n’oblige le développeur à utiliser this comme objet de synchronisation. On peut par exemple
utiliser un singleton si l’on souhaite synchroniser plusieurs méthodes disséminées dans plusieurs
objets.
Le principal reproche que l’on puisse faire à la technique du synchronized, c’est le manque de
granularité. En effet, si un système multi thread tente de lire et de modifier une variable en même
temps, le verrou sera le même pour la lecture ainsi que pour l’écriture, provoquant un goulot
d’étranglement.
Un verrou de lecture est différent d’un verrou d’écriture. Le verrou d’écriture doit attendre que les
verrous de lecture soient tous levés pour être posé. Plusieurs verrous de lecture peuvent être
posés en même temps alors qu’un seul verrou d’écriture ne peut être posé à un instant donné.
Ci-dessous une des nombreuses implémentations existantes.
class RWLock {
private int givenLocks;
private int waitingWriters;
private int waitingReaders;
private Object mutex;
public RWLock(Object mutex) {

this.mutex = mutex;
}
public void getReadLock() throws InterruptedException {

synchronized (mutex) {
while ((givenLocks == -1) || (waitingWriters != 0)) {
mutex.wait();
}
givenLocks++;
}
}

public void getWriteLock() throws InterruptedException {

waitingWriters++;
while (givenLocks != 0) {
mutex.wait();
}
waitingWriters--;
givenLocks = -1;
}
}
public void releaseLock() {

if (givenLocks == 0)
return;
if (givenLocks == -1)
givenLocks = 0;
else
givenLocks--;
mutex.notifyAll();
}
}
}
3.1.9Documentation
Nombre de codes sources sont encore livrés sans documentation, pourtant le besoin en
documentation technique sur un projet n’est plus à démontrer. Le souci principal est de savoir
quand la rédiger. Nécessairement pas au début du projet, car la plupart du temps, le fonctionnel
n’est pas stable et les commentaires bons auparavant, deviennent rapidement caduques. La
maintenance de la documentation devient fastidieuse et donne au développeur l’impression de
travailler pour rien. Il est préférable de le faire à la fin de chaque itération, c'est-à-dire chaque fois
qu’un module est considéré comme stable et pratiquement finalisé.
3.1.10 Exception
Les exceptions doivent refléter l’erreur levée. Trouvez la bonne granularité : une interface
graphique se moque de savoir que c’est la base de données qui ne répond pas. Elle a juste besoin
de savoir que le service est momentanément interrompu. Le niveau de précision (la granularité)
de l’exception doit être adapté à la position du module dans une architecture en couche.
Au passage n’hésitez pas à enrichir la classe d’Exception de données complémentaires (Objet

Client, Facture, etc.) pour que les messages remontés soient plus clairs et que la recherche du
bug soient facilitée.
3.1.11 Paramètres de méthodes

Chaque objet à la responsabilité de ses données mais aussi de leurs cohérences (cf. pattern
Expert du GRASP). Il convient donc de tester les valeurs des paramètres reçus dans une méthode
ou un constructeur afin de ne pas introduire :
D’incohérences dans les données de la classe par une affectation.

D’incohérences dans les traitements par son utilisation.
De levée d’Exception si une valeur nulle est utilisée.
Dans l’exemple ci-dessous si param1 est à null la méthode lèvera un « NullPointerException »
public void theMethod(String param1, String param2) {

//si param1 est null, il y a levé d’Exception

if(param1.compareTo("str")==0) {
//...
}
Il est préférable d’écrire

public void theMethod(String param1, String param2) {
if(param1 == null) {
throw new IllegalArgumentException("param1 can't be null");
}
if(param2 == null) {
throw new IllegalArgumentException("param2 can't be null");
}
//...
if(param1.compareTo("str")==0) {
//...
}
}
Le client de la méthode va recevoir une exception de type « IllegalArgumentException » avec un
message représentatif de l’erreur.
3.2 Principes
3.2.1Ressources
Il arrive que certaines ressources (stream, connexion, …) soient initialisées à un endroit de
l’application et libérées à un autre. Le contrôle de la réservation et de la libération de la ressource
est difficile car disséminé. Placez l’acquisition et la libération des ressources si possible dans la
même méthode. En effet, si le programme lève une exception, rien ne certifie que la ou les
ressources seront libérées.
3.2.2Héritage
Il n’est pas rare de découvrir des arbres d’héritages à plusieurs niveaux. Au-delà de 3, dites-vous
que c’est trop et cela nuit à la lisibilité et à la compréhension du code. Préférez la délégation à
l’héritage : on n’expose que le nécessaire et par-là même on simplifie les objets. Souvenez-vous :
l’héritage ne sert pas à factoriser du code (cf. pattern Liskov substitution du GRAP).
Figure 82 Héritage trop complexe !!

3.2.3Habitude
L’ennemi du développeur. L’habitude d’utiliser le même algorithme quelque soit le cas d’utilisation
(tri bulle sur des millions de lignes), utiliser la même classe pour faire des choses différentes
(Utiliser un Vector alors qu’il faudrait un Stack ou un ArrayList).
3.2.4Simplicité
Tout logiciel est appelé à évoluer. Le risque serait de développer beaucoup de point d’ouverture
(cf. Open/Close principle) dans l’espoir que l’application évoluera sur ces points d’ouverture. C’est
une perte de temps : il est préférable de faire un refactoring de la partie concernée en temps
voulu. Evidemment, ce principe doit être accompagné d’un couplage faible des modules.
Finalement, choisissez toujours la simplicité, ne codez que ce qui est nécessaire car tout code
supplémentaire devra quand même être maintenu, documenté et testé sans ne jamais servir un
jour.
3.3 Mémoire
3.3.1Durée de vie des objets
Là où C++ doit explicitement allouer et désallouer les objets, java offre le garbage collector. C'est-
à-dire qu’un objet est libéré lorsqu’il n’est plus référencé par aucun autre objet. Ce concept simple
est pourtant pernicieux : en effet sur un modèle objet évènementiel où les références sont en
dépendance inverse (Observer/Observable) elles ne sont jamais relâchées. Dans ce cas de figure,
plusieurs solutions :
1. Utilisez des « Weak references ».

2. Relâchez explicitement le listener.
3. Jouez sur la durée de vie de la poigné sur l’objet.
Ne pas profiter de l’existence du garbage collector pour instancier beaucoup d’objets sans se
soucier de l’occupation mémoire. La machine virtuelle est obligée de consommer une partie des
ressources pour libérer les objets, donc moins vous instanciez d’objets, moins cela est coûteux en
mémoire mais aussi en temps.
Parfois positionner à « null » en cours de traitement un attribut de classe peut être une
optimisation si celui-ci pointe vers un objet gourmand (globalement le système est plus léger).
3.3.2Allocation mémoire
Si votre application nécessite l’utilisation de beaucoup d’objets, ne faites pas de « new »
systématique. Utiliser plutôt un pool d’objets (beaucoup d’implémentations existent), vous
économiserez le temps du garbage collector pour allouer/désallouer les espaces mémoires.
3.4 Conception
3.4.1The God Class
La « classe divine » (ou blob) est un anti-pattern facile à reconnaître par sa forme. Il est souvent
composé d’une classe principale de traitement. Sur le diagramme de classe de l’application il est
facile à repérer puisque cette classe est la plus grande (en nombre de méthodes) et référence
quasiment toutes les autres. Le blob contient la majorité des processus et utilise une multitude de
classes qui ne servent qu’à porter les données.

La « classe divine » va à l’encontre de la conception objet. La classe n’est pas réutilisable,

complexe à maintenir et difficile à tester (classe peu cohésive). De plus l’utilisation de cette classe
risque d’entraîner un coût mémoire important dès qu’on l’utilise, pour peu que l’initialisation de
toutes les variables soit dans le constructeur. Ce type de classe peut malgré tout être toléré si elle
n’est qu’un point d’entrée vers un système central ou distant.
Pour corriger ce problème, la classe doit être éclatée en plusieurs autres plus cohésives. La
répartition des méthodes doit être faite en respectant une certaine cohésion technique ou
fonctionnelle (cf. High cohesion GRASP).
3.4.2Swiss Army Knife

L’anti-pattern couteau suisse est le résultat d’une interface ou d’une classe dont le concepteur
souhaite répondre à toutes les attentes ou tous les cas possibles même futurs. Le nombre de
méthodes est élevé est la prise en main difficile. Proche du blob à la différence que le couteau
suisse tente de répondre à tous les besoins possibles alors que le blob monopolise les traitements
du système.
3.4.3Lava Flow
L’écoulement de lave est le résultat d’un développement sans conception plus communément
appelé « Quick and Dirty » qui a été mis en production avant toute stabilisation. Le résultat est
que la coulée de lave se solidifie et que les modifications ne sont plus possible puisque utilisé par
d’autres modules. On peut aisément se représenter le résultat de cette pratique sur une
application au bout de quelques années : l’application devient couteuse à maintenir et le
refactoring devient inévitable.
3.4.4No OO
Ce pattern non « Object Oriented » est le résultat d’un développement non-objet d’une
application. Le tout ressemble à un programme procédural et ne possède aucune construction
objet. L’héritage est bien sûr absent et le tout est d’une forte complexité. Des noms de méthodes
et de variables utilisant les normes d’un autre langage et un diagramme de classe sans relations
vous mettront sur la piste de ce type d’anti-patterns. Face à ce type de problème, il existe peu de
solutions car l’application est « architecturalement défectueuse » donc quasiment irrécupérable.
3.4.5Proliferation of Classes
La prolifération de classes peut s’observer dans certaines conceptions objets où les pratiques de
patterns sont excessives. Le principe de répartition des responsabilités est poussé à l’extrême et il
arrive que certaines classes n’existent que le temps d’une invocation de méthode. On les appelle
aussi classes « poltergeists » en comparaison aux phénomènes paranormaux qui apparaissent et
disparaissent en quelques secondes. Globalement, ces classes augmentent inutilement le nombre
total de classes et alourdissent le système puisque le garbage collector doit passer du temps pour
libérer les ressources. Il est préférable de centraliser tous les messages par type dans une classe
(cf. pattern Mediator du GOF).
3.4.6Golden Hammer
Ou comment tout faire avec un seul outil. Il est difficile, une fois que l’on maîtrise parfaitement un
outil, d’explorer des solutions alternatives. A chaque nouveau développement on tente d’utiliser
cet outil. Par exemple, vous maîtrisez parfaitement les EJB Entity et le projet suivant nécessite des
requêtes dynamiques avec un grand volume de données. L’erreur serait de vouloir absolument
utiliser les EJB alors qu’a priori un ORM, serait plus approprié. Au final, la solution est inadaptée et
sûrement moins performante, les développeurs ne sortent pas de leur technologie fétiche et
finissent rapidement par être « dépassés ». La solution est de faire une étude (même minimale)
avant d’utiliser systématiquement le même outil. Si le travail est déjà réalisé, le mal est déjà fait et
des pans entiers de l’application devront être refondus.
3.4.7Spaghetti code
Certainement un des anti-patterns les plus célèbres car il existe depuis la nuit des temps
informatiques. Le couplage de l’application est très fort et la cohésion faible ce qui rend la
maintenance hasardeuse. La réutilisation est inexistante et aucun des principes objets n’est
respecté. On remarque aussi une utilisation forte de méthodes sans paramètres et de variables
globales et publiques. Au même titre que l’anti-pattern No OO le refactoring est quasiment
impossible.
3.4.8Reinvent The Wheel

L’une des grandes promesses de l’approche objet c’est de pouvoir réutiliser les éléments logiciels.
Dans le même esprit il est préférable d’utiliser une brique logicielle (ou Framework) déjà testée et
développée par un tiers plutôt que de partir d’une feuille blanche. Aujourd’hui commencer un
projet en codant de A à Z une couche de persistance serait une hérésie. Avant de coder un
Framework ou une fonctionnalité complexe, faite une recherche sur internet pour voir si une
librairie ne propose pas déjà la solution.

4 CONCLUSION
4.1 A retenir
Les design patterns représentent un espace d’exploration très riche pour simplifier ou optimiser
votre code. Attention cependant de ne pas tomber dans la « patternite aïgue » : la conception
objet est un juste équilibre entre ce qui est possible et ce qui est nécessaire ; à vous de le trouver.
Les patterns sont là pour vous faire gagner du temps : ils améliorent la flexibilité et la réutilisation,
à vous de trouver aussi la bonne granularité.
Au final souvenez-vous que les patterns sont la capitalisation d’expériences et qu’il y a toujours
intérêt à les utiliser. Ils ne sont que des formes qui se mémorisent et s’adaptent facilement.
Bonne conception ;-)
4.2 Et après ?
Comme nous avons put le voir, les designs patterns simplifient l’approche par des motifs et une
conception standardisée. Peut-on alors conclure que les patterns sont (enfin ?) la réponse ultime
aux problématiques récurrentes de conception ?
Pas vraiment. En effet ils apportent un langage commun aux développeurs mais ne règlent pas
l’enchevêtrement du code métier et du pattern associé qui en résulte. Lorsque vous utilisez un
motif Strategy, vous répartissez le code métier dans plusieurs classes distinctes. Le couplage entre
les classes est toujours présent et les aspects techniques et métiers sont toujours mélangés.
Un début de solution semble émerger avec la technologie AOP (Aspect Oriented Programmming).
Le couplage entre les classes est quasi inexistant et la séparation entre les différents aspects
(technique et métier) est possible via l’utilisation d’un tisseur applicatif.
Vous trouverez de plus amples renseignements sur l’AOP à l’adresse suivante :

http://aosd.net/
4.3 Code source

4.3.1Création
4.3.1.1 AbstractFactory
4.3.1.1.1 Factory
01 package com.arnbe.patterns.creational.abstractfactory;
02
03 /**
04 * interface des Factory
05 */
06 public interface Factory {
07
08 /**
09 * fabrique un objet
10 *
11 * @return l'objet construit
12 */
13 public abstract Vehicule build();
14 }
4.3.1.1.2 TruckFactory
02
03 /**
04 * fabrique d'objet de type Truck
05 *
06 */
07 public class TruckFactory implements Factory {

08
09 /*
10 * (non-Javadoc)
11 * @see com.arnbe.patterns.creational.abstractfactory.Factory#build()
12 */
13 public Vehicule build() {
14 return new Truck();
15 }
16 }
4.3.1.1.3 PlaneFactory
02
03 /**
04 * fabrique d'objet de type Plane
05 *
06 */
07 public class PlaneFactory implements Factory {
08
09 /*
10 * (non-Javadoc)
11 * @see com.arnbe.patterns.creational.abstractfactory.Factory#build()
12 */
13 public Vehicule build() {
14 return new Plane();
15 }
16 }
4.3.1.1.4 Vehicule
02
03 /**
04 * interface des véhicules
05 */
06 public interface Vehicule {
07
08
09 /**
10 * démarre le moteur
11 *
12 */
13 public void startEngine();
14 }
4.3.1.1.5 Truck
02
03 /**
04 * classe de type Truck
05 */
06 public class Truck implements Vehicule {
07
08 public void drive() {
09 //code...
10 }
11
12 /*
13 * (non-Javadoc)
14 * @see com.arnbe.patterns.creational.abstractfactory.Vehicule#startEngine()
15 */
16 public void startEngine() {
17 //code...
18 }
19 }
4.3.1.1.6 Plane
02
03 /**
04 * classe de type Plane
05 */
06 public class Plane implements Vehicule {
07
08 public void fly() {
09 //code...
10 }
11
12 /*
13 * (non-Javadoc)
14 * @see com.arnbe.patterns.creational.abstractfactory.Vehicule#startEngine()
15 */
17 //code...
18 }
19 }

4.3.1.2 Builder
4.3.1.2.1 A380
01 package com.arnbe.patterns.creational.builder;
02
03 /**
04 * Classe d'un produit concret : l'A380
05 */
06
07 public class A380 implements Plane {
08
10 //code...
11 }
12
13 public void openFlap() {
14 //code...
15 }
16 }
4.3.1.2.2 A380Builder
02
03 /**
04 * crée les différentes parties de l'objet
05 */
06 public class A380Builder implements PlaneBuilder {
07
08 /**
09 * Référence vers le produit à construire
10 */
11 private A380 resultProduct = null;
12
13 /*
14 * (non-Javadoc)
15 * @see com.arnbe.patterns.creational.builder.PlaneBuilder#getResult()
16 */
17 public Plane getResult() {
18 return resultProduct;
19 }
20
21 public void buildEngine() {
22 //code...
23 }
24
25 public void buildWing() {
26 //code...
27 }
28 }
4.3.1.2.3 Director
02
03 /**
04 * prend en charge l'ordre de construction de l'objet
05 * à partir des méthodes des monteurs
06 */
07
08 public class Director {
09
10 /**
11 * @link aggregationByValue
12 */
13
14 private PlaneBuilder builder = null;
15
16 /**
17 * constructeur
18 *
19 * @param builder
20 */
21 public Director(PlaneBuilder builder) {
22 this.builder = builder;
23 }
24
25 /**
26 * controler la construction de l'objet
27 *
28 */
29 public void build() {
30 //on construit les ailes avant de poser les moteurs en dessous
31 builder.buildWing();
32 builder.buildEngine();
33 //...
34 }
35 }

4.3.1.2.4 Plane
02
03 /**
04 * représente l'interface communes aux avions
05 *
06 */
07 public interface Plane {
08 /**
09 * démarre le moteur
10 */
11 public void startEngine();
12
13 /**
14 * ouverture des flaps
15 */
16 public void openFlap();
17 }
4.3.1.2.5 PlaneBuilder
02
03 /**
04 * interface de chaque monteur d'avion
05 */
06 public interface PlaneBuilder {
07
08 /**
09 * Construit les moteurs
10 */
11 public void buildEngine();
12
13 /**
14 * construit les ailes de l'avion
15 */
16 public void buildWing();
17
18 /**
19 * @return le produit construit
20 */
21 Plane getResult();
22 }
4.3.1.3 FactoryMethod
4.3.1.3.1 Product
1 package com.arnbe.patterns.creational.factorymethod;
2
3 /**
4 * interface des produits
5 */
6 public interface Product {
7 }
4.3.1.3.2 Truck
2
3 /**
4 * Produit concret utilisé par TruckCreator
5 */
6 public class Truck implements Product {
7 }
4.3.1.3.3 AbstractCreator
02
03 /**
04 * Classe mère
05 */
06 public abstract class AbstractCreator {
07
08 /**
09 * méthode de construction à implémenter
10 *
11 * @return
12 */
13 public abstract Product factoryMethod();
14
15 /**
16 * utilisation
17 *
18 */
19 public void sampleUse() {
20 // ...

21 Product product = factoryMethod();

22 // ...
23 }
24 }
4.3.1.3.4 TruckCreator
02
03 /**
04 * Hérite pour fournir un créateur concret
05 */
06
07 public class TruckCreator extends AbstractCreator {
08
09 /*
10 * (non-Javadoc)
11 * @see com.arnbe.patterns.creational.factorymethod.AbstractCreator#factoryMethod()
12 */
13 public Product factoryMethod() {
14 return new Truck();
15 }
16 }
4.3.1.4 Prototype
4.3.1.4.1 Prototype
1 package com.arnbe.patterns.creational.prototype;
2
3 /**
4 * Classe mère
5 */
6 public interface Prototype {
7
8 Prototype clone();
9 }
4.3.1.4.2 Plane
02
03 /**
04 * Classe ayant la capacité de se cloner
05 */
06 public class Plane implements Prototype {
07
08 protected Plane(Plane prototype) {
09 //constructeur permettant d'initialiser un prototype à partir d'un autre
10 }
11
12 public Prototype clone() {
13 return new Plane(this);
14 }
15 }
4.3.1.4.3 Truck
02
03 public class Truck implements Prototype {
04
05 protected Truck(Truck prototype) {
06 //constructeur permettant d'initialiser un prototype à partir d'un autre
07 }
08
09 public Prototype clone() {
10 return new Truck(this);
11 }
12 }
4.3.1.5 Singleton
4.3.1.5.1 Singleton
01 package com.arnbe.patterns.creational.singleton;
02
03 /**
04 * Represente un singleton.
05 */
06
07 public class Singleton {
08
09 /**
10 * Poignée sur le singleton
11 */
12 private static Singleton instance=null;
13
14 /**

15 * Constructeur privé pour interdire toute instanciation extérieure

16 */
17 private Singleton() {
18 //code...
19 }
20
21 /**
22 * Retourne l'instance du singleton : si elle n'existe pas, elle est crée
23 @return le singleton
24 */
25 static public Singleton getInstance() {
26 if (instance == null) {
27 instance = new Singleton();
28 }
29 return instance;
30 }
31 }
4.3.2Structure
4.3.2.1 Adapter
4.3.2.1.1 IteratorEnumerationAdapter
01 package com.arnbe.patterns.structural.adapter;
02
03 import java.util.Enumeration;
04 import java.util.Iterator;
05
06 public class IteratorEnumerationAdapter implements Iterator {
07
08 /** énumération interne */
09 private Enumeration internEnum = null;
10
11 /**
12 * constructeur
13 *
14 * @param enumeration
15 */
16 public IteratorEnumerationAdapter(Enumeration enumeration) {
17 internEnum = enumeration;
18 }
19
20 /*
21 * (non-Javadoc)
22 * @see java.util.Iterator#hasNext()
23 */
24 public boolean hasNext() {
25 return internEnum.hasMoreElements();
26 }
27
28 /*
29 * (non-Javadoc)
30 * @see java.util.Iterator#next()
31 */
32 public Object next() {
33 return internEnum.nextElement();
34 }
35
36 /*
37 * (non-Javadoc)
38 * @see java.util.Iterator#remove()
39 */
40 public void remove() {
41 //ici une exception de type Runtime est lancée, car la notion de remove n'existe pas
42 //pour l'interface Enumeration
43 throw new UnsupportedOperationException("IteratorEnumerationAdapter ne supporte pas la suppression d'éléments");
44 }
45 }
4.3.2.2 Bridge
4.3.2.2.1 AbstractCustomers
01 package com.arnbe.patterns.structural.bridge;
02
03 /**
04 * Classe mère
05 */
06 public abstract class AbstractCustomers {
07
08 /**
09 * Reference vers l'Implémentor
10 */
11 private DataObject impl = null;
12 protected String group = null;
13
14 /**
15 * constructeur
16 *
17 * @param group nom du groupe de client
18 */
19 public AbstractCustomers(String group) {

20 this.group = group;
21 }
22
23 /**
24 * @return implementation-in-action.
25 */
26 protected DataObject getImplementor() {
27 return impl;
28 }
29
30 /**
31 *
32 * @param impl
33 */
34 public void setImplementor(DataObject impl) {
35 this.impl = impl;
36 }
37
38 /**
39 * ajoute un client
40 * @param name nom du client
41 */
42 public void add(String name) {
43 impl.addRecord(name);
44 }
45
46 /**
47 * se positionne sur l'enregistrement suivant
48 */
49 public void next() {
50 impl.nextRecord();
51 }
52
53 /**
54 * se positionne sur l'enregistrement précédent
55 */
56 public void previous() {
57 impl.previousRecord();
58 }
59
60 /**
61 * supprime le client correspondant au nom
62 * @param name nom du client à supprimer
63 */
64 public void remove(String name) {
65 impl.removeRecord(name);
66 }
67 }
4.3.2.2.2 Customers
02
03 /**
04 * Classe concrète Customers
05 */
06 public class Customers extends AbstractCustomers {
07
08 public Customers(String group) {
09 super(group);
10 }
11 }
4.3.2.2.3 DataObject
02
03 /**
04 * classe mère des containers de données
05 */
06 public abstract class DataObject {
07
08 /**
09 * supprime l'enregistrement correspondant au nom
10 *
11 * @param name nom de l'objet à supprimer
12 */
13 public abstract void removeRecord(String name);
14
15 /**
16 * ajoute un enregistrement avec le nom en paramètre
17 *
18 * @param name nom de l'enregistrement à ajouter
19 */
20 public abstract void addRecord(String name);
21
22 /**
23 * se positionne sur l'enregistrement suivant
24 */
25 public abstract void nextRecord();
26
27 /**
28 * se positionne sur l'enregistrement précédent
29 */
30 public abstract void previousRecord();
31 }

4.3.2.2.4 InMemoryData
03
04 import java.util.ArrayList;
05
06 /**
07 * implémentation du DataObject sous forme d'un tableau mémoire
08 */
09 public class InMemoryData extends DataObject {
10
11 private ArrayList<String> dataList = new ArrayList<String>();
12 private int current = 0;
13
14 public InMemoryData() {
15 super();
16 //ce code est ici uniquement pour l'exemple
17 //les données pourront être lues depuis une base de données par exemple
18 //ou fourni par une classe dédiée
19 dataList.add("bertrand dupond");
20 dataList.add("daffy duck");
21 dataList.add("georges laforet");
22 dataList.add("frederic lepage");
23 }
24
25 /*
26 * (non-Javadoc)
27 * @see com.arnbe.patterns.structural.bridge.DataObject#nextRecord()
28 */
29 @Override
30 public void nextRecord() {
31 if(current <= dataList.size()-1) {
32 current++;
33 }
34 }
35
36 /*
37 * (non-Javadoc)
38 * @see com.arnbe.patterns.structural.bridge.DataObject#previousRecord()
39 */
40 @Override
41 public void previousRecord() {
42 if(current > 0) {
43 current--;
44 }
45 }
46
47 /*
48 * (non-Javadoc)
49 * @see com.arnbe.patterns.structural.bridge.DataObject#removeRecord()
50 */
51 @Override
52 public void removeRecord(String name) {
53 dataList.remove(name);
54 }
55
56 /*
57 * (non-Javadoc)
58 * @see com.arnbe.patterns.structural.bridge.DataObject#addRecord(java.lang.String)
59 */
60 @Override
61 public void addRecord(String name) {
62 dataList.add(name);
63 }
64 }
4.3.2.3 Composite
4.3.2.3.1 Product
001 package com.arnbe.patterns.structural.composite;
002
003 import java.util.HashMap;
005 import java.util.Map;
006
007 /**
008 * Classe des produits
009 * elle peut contenir des objets de type Produit
010 *
011 */
012 public class Product {
013
014 /** parent du produit */
015 private Product parent = null;
016
017 private String id = null;
018
019 private String label = null;
020
021 /** map des produits enfants */
022 private Map<String, Product> lnkProduct = new HashMap<String, Product>();
023

024 /**
025 * constructeur
026 * @param id du produit
027 * @param label du produit
028 */
029 public Product(String id, String label) {
030 super();
031 this.id = id;
032 this.label = label;
033 }
034
035 /**
036 * ajoute un produit
037 *
038 * @param product
039 */
040 protected void addProduct(Product productChild) {
041 productChild.setParent(this);
042 lnkProduct.put(productChild.getId(), productChild);
043 }
044
045 /**
046 * recherche un produit parmis les enfants
047 * @param id
048 * @return
049 */
050 protected Product getProduct(String id) {
051 return lnkProduct.get(id);
052 }
053
054 /**
055 * retourne une itération des produits enfants
056 * @return
057 */
058 protected Iterator<Product> getProducts() {
059 return lnkProduct.values().iterator();
060 }
061
062 /**
063 * retire un produit parmis les enfants
064 *
065 * @param id
066 * @return
067 */
068 protected void removeProduct(String id) {
069 Product p = lnkProduct.remove(id);
070 if(p!=null) {
071 p.setParent(null);
072 }
073 }
074
075 /**
076 * retourne le label
077 *
078 * @return
079 */
080 public String getLabel() {
081 return label;
082 }
083
084 /**
085 * retourne l'id du produit
086 *
087 * @return
088 */
089 public String getId() {
090 return id;
091 }
092
093 /**
094 * retourne le parent du produit
095 *
096 * @return
097 */
098 public Product getParent() {
099 return parent;
100 }
101
102 /**
103 * positionne le parent du produit
104 *
105 * @param parent
106 */
107 protected void setParent(Product parent) {
108 this.parent = parent;
109 }
110 }
4.3.2.3.2 ProductComposite
01 package com.arnbe.patterns.structural.composite;
02
04
05 public class ProductComposite {
06

07 /** produit racine de l'arborescence */

08 Product rootProduct = null;
09
10 /**
11 * constructeur
12 *
13 * @param root
14 */
15 public ProductComposite(Product root) {
16 rootProduct = root;
17 }
18
19 /**
20 * ajoute un produit sous le parent définie par l'id
21 *
22 * @param child
23 * @param parent
24 */
25 public void addProduct(Product child, String parentId) {
26 Product p = findProduct(rootProduct, parentId);
27 if(p != null) {
28 p.addProduct(child);
29 } else {
30 throw new IllegalStateException("can't find parent product");
31 }
32 }
33
34 /**
35 * supprime le produit de l'arborescence
36 *
37 * @param id
38 * @return
39 */
40 public void removeProduct(String id) {
41 Product product = findProduct(rootProduct, id);
42 if(product!=null) {
43 Product parent = product.getParent();
44 parent.removeProduct(id);
45 }
46 }
47
48 /**
49 * recherche un produit dans le graph d'objet
50 * la méthode n'est pas efficace mais suffit pour l'exemple
51 *
52 * @param product
53 * @param id
54 * @return
55 */
56 private Product findProduct(Product product, String id) {
57 if(product.getId().equals(id)) {
58 return product;
59 }
60 //cherche dans les childs
61 for (Iterator<Product> iterProduct = product.getProducts(); iterProduct.hasNext();) {
62 Product productChild = findProduct(iterProduct.next(), id);
63 if(productChild!=null) {
64 return productChild;
65 }
66 }
67 return null;
68 }
69 }
4.3.2.4 Decorator
4.3.2.4.1 Book
01
02 package com.arnbe.patterns.structural.decorator;
03
04 /**
05 * Classe Book
06 */
07 public class Book extends LibraryItem {
08
09 private String author = null;
10 private String title = null;
11
12 /**
13 * constructeur
14 *
15 * @param author
16 * @param title
17 * @param numCopies
18 */
19 public Book(String author, String title, int numCopies) {
20 super();
21 this.author = author;
22 this.title = title;
23 this.numCopies = numCopies;
24 }
25
26 /*
27 * (non-Javadoc)
28 * @see com.arnbe.patterns.structural.decorator.LibraryItem#display()
29 */

30 @Override
31 public void display() {
32 System.out.println("");
33 System.out.println("Books");
34 System.out.println("Author : " + author);
35 System.out.println("Title : " + title);
36 System.out.println("Copies : " + numCopies);
37 }
38 }
4.3.2.4.2 Video
03
04 /**
05 * Classe Video
06 */
07 public class Video extends LibraryItem {
08
09 private String director = null;
10 private String title = null;
11 private int playTime = 0;
12
13 /**
14 * constructeur
15 *
16 * @param director
17 * @param title
18 * @param playTime
19 * @param numCopies
20 */
21 public Video(String director, String title, int playTime, int numCopies) {
22 super();
23 this.director = director;
24 this.title = title;
25 this.playTime = playTime;
26 this.numCopies = numCopies;
27 }
28
29 /*
30 * (non-Javadoc)
32 */
33 @Override
35 System.out.println("");
36 System.out.println("Videos");
37 System.out.println("Director : " + director);
38 System.out.println("Title : " + title);
39 System.out.println("Copies : " + numCopies);
40 System.out.println("PlayTime : " + playTime);
41 }
42 }
4.3.2.4.3 Borrowable
02
04
05 /**
06 * Cette classe ajoute des responsabilités aux classes qui hérite de LibraryItem
07 */
08
09 public class Borrowable extends Decorator {
10
11 /** liste des emprunteurs du média */
12 protected ArrayList<String> borrowers = new ArrayList<String>();
13
14 /**
15 * constructeur
16 *
17 * @param component
18 */
19 public Borrowable(LibraryItem component) {
20 super(component);
21 }
22
23 /**
24 * le média est emprunté
25 *
26 * @param name
27 */
28 public void borrowItem(String name) {
29 borrowers.add(name);
30 librairyItem.numCopies--;
31 }
32
33 /**
34 * le média est rendu
35 *
36 * @param name
37 */
38 public void returnItem(String name) {
39 borrowers.remove(name);
40 librairyItem.numCopies++;

41 }
42
43 /* (non-Javadoc)
44 * @see com.arnbe.patterns.structural.decorator.Decorator#display()
45 */
46 @Override
48 super.display();
49 //ici commence l'ajout de responsabilité
50 for (String borrower : borrowers) {
51 System.out.println("Borrower : " + borrower);
52 }
53 }
54 }
4.3.2.4.4 Decorator
02
03 /**
04 *
05 */
06 public abstract class Decorator extends LibraryItem {
07
08 /**
09 * référence vers l'élément à décorer
10 */
11 protected LibraryItem librairyItem = null;
12
13 /**
14 * constructeur
15 *
16 * @param librairyItem
17 */
18 public Decorator(LibraryItem librairyItem) {
19 this.librairyItem = librairyItem;
20 }
21
22 /* (non-Javadoc)
24 */
25 @Override
27 librairyItem.display();
28 }
29 }
4.3.2.4.5 LibraryItem
02
03 /**
04 * Element de la librairie
05 */
06 public abstract class LibraryItem {
07
08 /** nombre de copies libre dans la librairie */
09 protected int numCopies = 0;
10
11 /** affiche le contenu de l'objet */
12 public abstract void display();
13
14 }
4.3.2.5 Facade
4.3.2.5.1 Compiler
01 package com.arnbe.patterns.structural.facade;
02
03 public class Compiler {
04
05 private CodeGenerator lnkCodeGenerator = null;
06 private Parser lnkParser = null;
07 private Scanner lnkScanner = null;
08
09 public Compiler() {
10 super();
11 lnkCodeGenerator = new CodeGenerator();
12 lnkScanner = new Scanner();
13 lnkParser = new Parser();
14 }
15
16 public void compile() {
17 //code...
18 lnkScanner.scan();
19 lnkParser.parse();
20 lnkCodeGenerator.generate();
21 //code...
22 }
23 }

4.3.2.6 Flyweight
4.3.2.6.1 Character
01 package com.arnbe.patterns.structural.flyweight;
02
03 /**
04 * composant FlyWeight etclasse mère des caractères
05 */
06 public abstract class Character implements GraphicalItem {
07
08 /** code du symbol */
09 protected char symbol;
10
11 /** largeur en point */
12 protected int width;
13
14 /** hauteur en point */
15 protected int height;
16
17
18 /*
19 * (non-Javadoc)
20 * @see com.arnbe.patterns.structural.flyweight.GraphicalItem#display(com.arnbe.patterns.structural.flyweight.Context)
21 */
22 public void display(Context context) {
23 System.out.println(symbol + " (Font " + context.getFont() + ")");
24 }
25 }
4.3.2.6.2 CharacterA
02
03 /**
04 *
05 *
06 */
07 public class CharacterA extends Character {
08
09 public CharacterA() {
10 this.symbol = 'A';
11 this.height = 100;
12 this.width = 120;
13 }
14 }
4.3.2.6.3 CharacterB
02 /**
03 *
04 *
05 */
06 public class CharacterB extends Character {
07
08 public CharacterB() {
09 this.symbol = 'B';
12 }
13 }
4.3.2.6.4 CharacterZ
02
03 /**
04 *
05 */
06 public class CharacterZ extends Character {
07
08 public CharacterZ() {
09 this.symbol = 'Z';
12 }
13 }
4.3.2.6.5 Context
02
03 public interface Context {
04
05 /** retourne la Font sur la position en cours */
06 public String getFont();
07
08 /** positionne le type de Font sur une plage de caractère pour une ligne donnée*/
09 public void setFont(String fontName, int rowNumber, int from, int to);
10 }

4.3.2.6.6 GraphicalItem
02
03 /**
04 *
05 */
06 public interface GraphicalItem {
07 /**
08 * méthode d'affichage de l'élément graphique
09 *
10 * @param context
11 */
12 public void display(Context context);
13 }
4.3.2.6.7 GraphicalItemFactory
02
04
05 /**
06 * Fabrique des caractères
07 */
08
09 public class GraphicalItemFactory {
10
11 /** stock des éléments graphiques déjà crée */
12 private HashMap<Integer, GraphicalItem> characters = null;
13
14 /**
15 * constructeur
16 *
17 */
18 public GraphicalItemFactory() {
19 characters = new HashMap<Integer, GraphicalItem>();
20 }
21
22 /**
23 * retourne le caractère demandé
24 * si il existe on ne crée pas de nouvelle instance
25 * sinon on en crée une nouvelle
26 * on peut parler de "lazy initialization"
27 *
28 * @param key
29 * @return
30 */
31 public Character getCharacter(char key) {
32 //verifie si l'objet n'existe pas déjà
33 Integer intKey = new Integer((int)key);
34 GraphicalItem gItem = characters.get(intKey);
35 if(gItem!=null) {
36 return (Character) gItem;
37 } else {
38 //ici le choix du type de classe à retourner
39 switch(key) {
40 case 'A' : gItem = new CharacterA(); break;
41 case 'B' : gItem = new CharacterB(); break;
42 //etc...
43 case 'Z' : gItem = new CharacterZ(); break;
44 }
45 characters.put(intKey, gItem);
46 return (Character) gItem;
47 }
48 }
49
50 /**
51 * @return new instance of unshared flyweight
52 */
53 public Row getRow(String content) {
54 return new Row(content);
55 }
56 }
4.3.2.6.8 PageContext
02
03 public class PageContext implements Context {
04
05 /** position du caractère courant */
06 private int currentCar = 0;
07 /** numéro de la ligne courante */
08 private int currentRow = 0;
09
10 /**
11 * constructeur
12 *
13 */
14 public PageContext() {
15 super();
16 }

17
18 /**
19 * positionne sur le caractère suivant de la ligne en cours
20 *
21 */
22 public void next() {
23 currentCar++;
24 }
25
26 /**
27 * passe à la ligne suivante
28 *
29 */
30 public void nextLine() {
31 currentRow++;
32 currentCar = 0;
33 }
34
35 /*
36 * (non-Javadoc)
37 * @see com.arnbe.patterns.structural.flyweight.Context#getFont()
38 */
39 public String getFont() {
40 //mettre ici le code pour retrouver la Font pour la ligne
41 //et la position donnée
42 return "Arial";
43 }
44
45 /*
46 * (non-Javadoc)
47 * @see com.arnbe.patterns.structural.flyweight.Context#setFont(java.lang.String, int, int, int)
48 */
49 public void setFont(String fontName, int rowNumber, int from, int to) {
50 //mettre ici le code pour stocker la Font sur la ligne
51 }
52 }
4.3.2.6.9 Row
02
03 /**
04 * Classe FlyWeight non partagée
05 * représente une ligne d'une page
06 */
07
08 public class Row implements GraphicalItem {
09
10 /** contenu de la ligne */
11 private String content = null;
12
13 /**
14 * constructeur
15 *
16 * @param content
17 */
18 public Row(String content) {
19 super();
20 this.content = content;
21 }
22
23 /**
24 * retourne le contenu de la ligne
25 * @return
26 */
27 public String getContent() {
28 return content;
29 }
30
31 /**
32 *
33 * @return
34 */
35 public char[] charArray() {
36 return content.toCharArray();
37 }
38
39 /*
40 * (non-Javadoc)
41 * @see com.arnbe.patterns.structural.flyweight.GraphicalItem#display(com.arnbe.patterns.structural.flyweight.Context)
42 */
43 public void display(Context context) {
44 System.out.println(content + " (length " + content.length() + ")");
45 }
46 }
4.3.2.7 Proxy
4.3.2.7.1 Graphic
01 package com.arnbe.patterns.structural.proxy;
02
03 /**
04 * Interface d'élément graphic
05 */

06 public interface Graphic {

07
08 /**
09 * méthode fonctionnelle
10 *
11 */
12 public void draw();
13
14 public void load();
15
16 public void store();
17
18 public void getExtent();
19 }
4.3.2.7.2 Image
02
03 /**
04 * Classe de l'objet réel
05 */
06
07 public class Image implements Graphic {
08
09 /*
10 * (non-Javadoc)
11 * @see com.arnbe.patterns.structural.proxy.Graphic#draw()
12 */
13 public void draw() {
14 lockWhileCompleted();
15 //code...
16 }
17
18 /*
19 * (non-Javadoc)
20 * @see com.arnbe.patterns.structural.proxy.Graphic#load()
21 */
22 public void load() {
24 //code...
25 }
26
27 /*
28 * (non-Javadoc)
29 * @see com.arnbe.patterns.structural.proxy.Graphic#store()
30 */
31 public void store() {
33 //code...
34 }
35
36 /*
37 * (non-Javadoc)
38 * @see com.arnbe.patterns.structural.proxy.Graphic#getExtent()
39 */
40 public void getExtent() {
42 //code...
43 }
44
45 /**
46 * méthode bloquante tant que l'image n'est pas chargée
47 *
48 */
49 private void lockWhileCompleted() {
50 //code...
51 }
52 }
4.3.2.7.3 ImageProxy
02
03 /**
04 * Classe de proxy pour une image
05 */
06
07 public class ImageProxy implements Graphic {
08
09 /**
10 * Poignée sur l'objet graphique
11 */
12 private Graphic subject = null;
13
14 /**
15 * constructeur
16 *
17 * @param subject
18 */
19 public ImageProxy(Graphic subject) {
20 super();
21 this.subject = subject;
22 }
23
24 /*

25 * (non-Javadoc)
26 * @see com.arnbe.patterns.structural.proxy.Graphic#draw()
27 */
28 public void draw() {
29 subject.draw();
30 }
31
32 /*
33 * (non-Javadoc)
34 * @see com.arnbe.patterns.structural.proxy.Graphic#load()
35 */
36 public void load() {
37 return;
38 }
39
40 /*
41 * (non-Javadoc)
42 * @see com.arnbe.patterns.structural.proxy.Graphic#store()
43 */
44 public void store() {
45 return;
46 }
47
48 /*
49 * (non-Javadoc)
50 * @see com.arnbe.patterns.structural.proxy.Graphic#getExtent()
51 */
52 public void getExtent() {
53 return;
54 }
55 }
4.3.3Comportement
4.3.3.1 Chain of responsability
4.3.3.1.1 Approver
01 package com.arnbe.patterns.behavioural.chainofresponsability;
02
03 /**
04 *
05 */
06 public abstract class Approver {
07
08 protected Approver successor = null;
09
10 /**
11 * méthode qui doit être surchargée
12 *
13 */
14 public abstract void handleRequest(Project p);
15
16 /**
17 * fixe le maillon suivant dans la chaine
18 *
19 * @param successor
20 */
21 public void setSuccessor(Approver successor) {
22 this.successor = successor;
23 }
24
25 /**
26 * retourne le maillon suivant de la chaine
27 *
28 * @return
29 */
30 public Approver getSuccessor() {
31 return successor;
32 }
33 }
4.3.3.1.2 Employee
02
03 /**
04 * Classe d'un employée
05 * elle a la capacité de recevoir des messages via la méthode
06 * handleRequest
07 */
08
09 public class Employee extends Approver {
10
11 private String function = null;
12
13 /**
14 * constructeur
15 *
16 * @param function
17 */
18 public Employee(String function) {
19 super();
20 this.function = function;

21 }
22
23 /**
24 * Gère le message ou le passe au suivant
25 */
26 @Override
27 public void handleRequest(Project p) {
28 boolean someCondition = false;
29 if (someCondition) {
30 //traite la requête
31 } else {
32 //passe au suivant dans la chaine si il existe
33 if (successor != null) {
34 successor.handleRequest(p);
35 }
36 }
37 }
38 }
4.3.3.1.3 Project
02
03 public class Project {
04
05 private String name = null;
06 private int amount = 0;
07
08 /**
09 * constructeur
10 *
11 * @param amount
12 * @param name
13 */
14 public Project(int amount, String name) {
15 super();
16 this.amount = amount;
17 this.name = name;
18 }
19
20 /**
21 * @return
22 */
23 public int getAmount() {
24 return amount;
25 }
26
27 /**
28 * @return
29 */
30 public String getName() {
31 return name;
32 }
33 }
4.3.3.2 Command
4.3.3.2.1 Calculator
01 package com.arnbe.patterns.behavioural.command;
02
03 /**
04 * classe contenant le traitement à mettre en oeuvre
05 *
06 * @author abarbe
07 *
08 */
09 public class Calculator {
10
11 private int curr = 0;
12
13 public void Operation(char operator, int operand) {
14 switch(operator) {
15 case '+': curr += operand; break;
16 case '-': curr -= operand; break;
17 case '*': curr *= operand; break;
18 case '/': curr /= operand; break;
19 }
20 System.out.println("Current value = " + curr + "(following " + operator + " " + operand + ")");
21 }
22 }
4.3.3.2.2 CalculatorCommand
02
03 /**
04 * Fait le lien entre le calculateur et une action
05 * à la connaissance pour défaire une action
06 */
07
08 public class CalculatorCommand implements Command {
09

10 char operator;
11 int operand;
12 Calculator calculator = null;
13
14 /**
15 * constructeur
16 *
17 * @param receiver
18 */
19 public CalculatorCommand(Calculator calculator, char operator, int operand) {
20 this.calculator = calculator;
21 this.operator = operator;
22 this.operand = operand;
23 }
24
25 /*
26 * (non-Javadoc)
27 * @see com.arnbe.patterns.behavioural.command.Command#execute()
28 */
29 public void execute() {
30 calculator.Operation(operator, operand);
31
32 }
33
34 /*
35 * (non-Javadoc)
36 * @see com.arnbe.patterns.behavioural.command.Command#unExecute()
37 */
38 public void unExecute() {
39 calculator.Operation(undo(operator), operand);
40 }
41
42 /**
43 * annule une opération
44 *
45 * @param operator
46 * @return
47 */
48 private char undo(char operator){
49 char undo;
50 switch(operator){
51 case '+': undo = '-'; break;
52 case '-': undo = '+'; break;
53 case '*': undo = '/'; break;
54 case '/': undo = '*'; break;
55 default : undo = ' '; break;
56 }
57 return undo;
58 }
59 }
4.3.3.2.3 Command
02 /**
03 * interface de la Commande
04 */
05 public interface Command {
06
07 /**
08 * méthode d'éxécution de la commande
09 */
10 public void execute();
11 /**
12 * méthode pour annuler la commande
13 *
14 */
15 public void unExecute();
16 }
4.3.3.2.4 User
02
04
05 /**
06 * classe de type Invoker
07 * c'est le point d'entrée du pattern
08 *
09 */
10 public class User {
11
12 private Calculator calculator = new Calculator();
13
14 /** liste des commands */
15 private ArrayList<Command> commands = new ArrayList<Command>();
16
18
19 /**
20 * rejoue les commandes jusqu'à un certain niveau
21 *
22 * @param levels
23 */
24 public void redo(int levels) {

25 for (int i = 0; i < levels; i++) {

26 if (current < commands.size() - 1) {
27 commands.get(current++).execute();
28 }
29 }
30 }
31
32 /**
33 * défait les commandes jusqu'à un certain niveau
34 *
35 * @param levels
36 */
37 public void undo(int levels) {
38 for (int i = 0; i < levels; i++) {
39 if (current > 0) {
40 commands.get(--current).unExecute();
41 }
42 }
43 }
44
45 /**
46 * créer un calcul par le biais d'une Command et l'execute
47 *
48 * @param operator
49 * @param operand
50 */
51 public void compute(char operator, int operand) {
52 Command command = new CalculatorCommand(calculator, operator, operand);
53 command.execute();
54
55 //ajoute la commande dans la list
56 commands.add(command);
57 current++;
58 }
59 }
4.3.3.3 Interpreter
4.3.3.3.1 Context
01 package com.arnbe.patterns.behavioural.interpreter;
02
03 public class Context {
04
05 private String input = null;
06
07 private int output;
08
09 public Context(String input) {
10 this.input = input;
11 }
12
13 /**
14 * retourne la chaine d'entrée
15 * @return
16 */
17 public String getInput() {
18 return input;
19 }
20
21 /**
22 * affecte la chaine d'input
23 * @param
24 */
25 public void setInput(String input) {
26 this.input = input;
27 }
28
29 /**
30 * retourne le contenu de la sortie
31 * @return
32 */
33 public int getOutput() {
34 return output;
35 }
36
37 /**
38 * affecte le contenu de la sortie
39 * @param
40 */
41 public void setOutput(int output) {
42 this.output = output;
43 }
44 }
4.3.3.3.2 Expression
02
03 /**
04 *
05 */
06 public abstract class Expression {
07
08 /**

09 * interprète le contenu du context

10 *
11 * @param context
12 */
13 public void interpret(Context context) {
14 if(context.getInput().length() == 0) {
15 return;
16 }
17
18 if(context.getInput().startsWith(nine())) {
19 context.setOutput(context.getOutput() + (9 * multiplier()));
20 context.setInput(context.getInput().substring(2));
21 }
22 else if(context.getInput().startsWith(four())) {
25 }
26 else if(context.getInput().startsWith(five())) {
29 }
30 while(context.getInput().startsWith(one())) {
33 }
34
35 }
36 public abstract String one();
37 public abstract String four();
38 public abstract String five();
39 public abstract String nine();
40 public abstract int multiplier();
41
42 }
4.3.3.3.3 HundredExpression
02
03 /**
04 * Implementation de la représentation d'un symbol
05 */
06
07 public class HundredExpression extends Expression {
08
09 /*
10 * (non-Javadoc)
11 * @see com.arnbe.patterns.behavioural.interpreter.Expression#one()
12 */
13 @Override
14 public String one() {
15 return "C";
16 }
17
18 /*
19 * (non-Javadoc)
20 * @see com.arnbe.patterns.behavioural.interpreter.Expression#four()
21 */
22 @Override
23 public String four() {
24 return "CD";
25 }
26
27
28
29 /*
30 * (non-Javadoc)
31 * @see com.arnbe.patterns.behavioural.interpreter.Expression#five()
32 */
33 @Override
34 public String five() {
35 return "D";
36 }
37
38 /*
39 * (non-Javadoc)
40 * @see com.arnbe.patterns.behavioural.interpreter.Expression#nine()
41 */
42 @Override
43 public String nine() {
44 return "CM";
45 }
46
47 /*
48 * (non-Javadoc)
49 * @see com.arnbe.patterns.behavioural.interpreter.Expression#multiplier()
50 */
51 @Override
52 public int multiplier() {
53 return 100;
54 }
55 }

4.3.3.3.4 OneExpression
02
03 /**
05 */
06 public class OneExpression extends Expression {
07
08 /*
09 * (non-Javadoc)
11 */
12 @Override
14 return "I";
15 }
16
17 /*
18 * (non-Javadoc)
20 */
21 @Override
23 return "IV";
24 }
25
26 /*
27 * (non-Javadoc)
29 */
30 @Override
32 return "V";
33 }
34
35 /*
36 * (non-Javadoc)
38 */
39 @Override
41 return "IX";
42 }
43
44 /*
45 * (non-Javadoc)
47 */
48 @Override
50 return 1;
51 }
52 }
4.3.3.3.5 TenExpression
02
03 /**
05 */
06 public class TenExpression extends Expression {
07
08 /*
09 * (non-Javadoc)
11 */
12 @Override
14 return "X";
15 }
16
17 /*
18 * (non-Javadoc)
20 */
21 @Override
23 return "XL";
24 }
25
26 /*
27 * (non-Javadoc)
29 */
30 @Override
32 return "L";
33 }
34
35 /*
36 * (non-Javadoc)
38 */
39 @Override

41 return "XC";
42 }
43
44 /*
45 * (non-Javadoc)
47 */
48 @Override
50 return 10;
51 }
52 }
4.3.3.3.6 ThousandExpression
02
03 /**
05 */
06 public class ThousandExpression extends Expression {
07
08 /*
09 * (non-Javadoc)
11 */
12 @Override
14 return "M";
15 }
16
17 /*
18 * (non-Javadoc)
20 */
21 @Override
23 return " ";
24 }
25
26 /*
27 * (non-Javadoc)
29 */
30 @Override
32 return " ";
33 }
34
35 /*
36 * (non-Javadoc)
38 */
39 @Override
41 return " ";
42 }
43
44 /*
45 * (non-Javadoc)
47 */
48 @Override
50 return 1000;
51 }
52 }
4.3.3.4 Iterator
4.3.3.4.1 AbstractCollection
1 package com.arnbe.patterns.behavioural.iterator;
2
3 public interface AbstractCollection {
4
5 public Iterator iterator();
6 }
4.3.3.4.2 Collection
02
03 /**
04 *
05 */
06 public class Collection implements AbstractCollection {
07
08 /** tableau des données */
09 Object[] content = null;
10
11 /**
12 *

13 */
14 public Collection(Object[] object) {
15 super();
16 this.content = object;
17 }
18
19 /**
20 * retourne un Iterator du contenu
21 */
22 public Iterator iterator() {
23 return new RealIterator(this);
24 }
25
26 /**
27 * retourne le nombre d'éléments dans la collection
28 *
29 * @return
30 */
31 public int size() {
32 return content.length;
33 }
34
35 /**
36 * retourne l'élément à la position donnée
37 *
38 * @param index
39 * @return
40 */
41 public Object get(int index) {
42 return content[index];
43 }
44 }
4.3.3.4.3 Iterator
2
3 public interface Iterator {
4
5 public Object next();
6
7 public boolean hasNext();
8 }
4.3.3.4.4 RealIterator
02
03 public class RealIterator implements Iterator {
04
05 private Collection aggregate = null;
07
08 /**
09 * constructeur
10 *
11 * @param aggregate
12 */
13 public RealIterator(Collection aggregate) {
14 this.aggregate = aggregate;
15 }
16
17 /**
18 * retourne l'élément suivant dans l'itérateur
19 */
20 public Object next() {
21 return aggregate.get(current++);
22 }
23
24 /**
25 * retourne true si il reste des éléments dans l'itérator
26 * false autrement
27 */
28 public boolean hasNext() {
29 return current < aggregate.size();
30 }
31 }
4.3.3.5 Mediator
4.3.3.5.1 AbstractChatroom
01 package com.arnbe.patterns.behavioural.mediator;
02
03 public interface AbstractChatroom {
04
05 /**
06 * enregistre un participant à la chatroom
07 * @param colleague
08 */
09 public void register(Participant colleague);
10
11 /**

12 * envoie un message aux participants de la chatroom

13 * @param from
14 * @param message
15 */
16 public void send(String from, String message);
17 }
4.3.3.5.2 CounterStrikeChatRoom
03
05
06
07 public class CounterStrikeChatroom implements AbstractChatroom {
08
09 /**
10 * @link aggregation
11 * @associates com.arnbe.patterns.behavioural.mediator.Fighter
12 * @directed directed
13 * @supplierCardinality 0..*
14 */
15 private HashMap<String, Participant> participants = new HashMap<String, Participant>();
16
17 /*
18 * (non-Javadoc)
19 * @see com.arnbe.patterns.behavioural.mediator.AbstractChatroom#register(com.arnbe.patterns.behavioural.mediator.Participant)
20 */
21 public void register(Participant participant) {
22 participants.put(participant.getName(), participant);
23 participant.setChatRoom(this);
24 }
25
26 /*
27 * (non-Javadoc)
28 * @see com.arnbe.patterns.behavioural.mediator.AbstractChatroom#send(java.lang.String, java.lang.String)
29 */
30 public void send(String from, String message) {
31 for (Participant participant : participants.values()) {
32 //on envoie pas le message à l'émetteur
33 if(!participant.getName().equals(from))
34 participant.receive(from, message);
35 }
36 }
37 }
4.3.3.5.3 Fighter
02
03 public class Fighter extends Participant {
04
05 /**
06 * constructeur
07 * @param name
08 */
09 public Fighter(String name) {
10 super(name);
11 }
12
13 /*
14 * (non-Javadoc)
15 * @see com.arnbe.patterns.behavioural.mediator.Participant#receive(java.lang.String, java.lang.String)
16 */
17 @Override
18 public void receive(String from, String message) {
19 System.out.println(name + " received \"" + message + "\" from " + from);
20 //code...
21
22 }
23 }
4.3.3.5.4 Participant
02
03 public abstract class Participant {
04
05 private AbstractChatroom chatRoom = null;
06 protected String name = null;
07
08 /**
09 * constructeur
10 * @param name
11 */
12 protected Participant(String name) {
14 }
15
16 /**
17 * affecte la chatRoom
18 * @return
19 */
20 public void setChatRoom(AbstractChatroom chatRoom) {

21 this.chatRoom = chatRoom;
22 }
23
24 /**
25 * envoie un message
26 * @param message
27 */
28 public void send(String message) {
29 chatRoom.send(name, message);
30 }
31
32 /**
33 * @return le nom de la chat room
34 */
36 return name;
37 }
38
39 /**
40 * recoie un message des participants
41 * @param message
42 */
43 public abstract void receive(String from, String message);
44 }
4.3.3.6 Memento
4.3.3.6.1 Car
01 package com.arnbe.patterns.behavioural.memento;
02
03 /**
04 * Classe dont les données doivent être sauvegardées
05 */
06 public class Car {
07
08 private String model = null;
09 private boolean airConditionning = false;
10 private boolean slidingRoof = false;
11
12 /**
13 * constructeur
14 * @param model
15 */
16 public Car(String model) {
17 super();
18 this.model = model;
19 }
20
21 /**
22 * @return
23 */
24 public boolean isAirConditionning() {
25 return airConditionning;
26 }
27
28 /**
29 * @param airConditionning
30 */
31 public void setAirConditionning(boolean airConditionning) {
32 this.airConditionning = airConditionning;
33 }
34
35 /**
36 * @return
37 */
38 public boolean isSlidingRoof() {
39 return slidingRoof;
40 }
41
42 /**
43 * @param slidingRoof
44 */
45 public void setSlidingRoof(boolean slidingRoof) {
46 this.slidingRoof = slidingRoof;
47 }
48
49
50 /**
51 * crée une sauvegarde de l'état des données à un instant
52 * @return
53 */
54 public CarMemento createMemento() {
55 return new CarMemento(airConditionning, slidingRoof);
56 }
57
58 /**
59 * restore les données à partir du memento
60 * @param memento
61 */
62 public void restoreMemento(CarMemento memento) {
63 if (memento instanceof CarMemento) {
64 CarMemento cm = memento;
65 this.airConditionning = cm.isAirConditionning();
66 this.slidingRoof = cm.isSlidingRoof();
67 }

68 }
69 }
4.3.3.6.2 CarMemento
02
03 /**
04 * Ne sauvegarde que les options du véhicule
05 */
06 public class CarMemento {
07
08 private boolean airConditionning = false;
09 private boolean slidingRoof = false;
10
11 /**
12 * constructeur
15 */
16 public CarMemento(boolean airConditionning, boolean slidingRoof) {
17 super();
20 }
21 /**
22 * @return
23 */
24 public boolean isAirConditionning() {
25 return airConditionning;
26 }
27 /**
29 */
30 public void setAirConditionning(boolean airConditionning) {
32 }
33 /**
34 * @return
35 */
36 public boolean isSlidingRoof() {
37 return slidingRoof;
38 }
39 /**
41 */
42 public void setSlidingRoof(boolean slidingRoof) {
44 }
45 }
4.3.3.6.3 CarMemory
02
03 /**
04 * maintient une poignée vers le memento
05 *
06 */
07 public class CarMemory {
08
09 private CarMemento memento = null;
10
11 /**
12 * @return
13 */
14 public CarMemento getMemento() {
15 return memento;
16 }
17
18 /**
19 * @param memento
20 */
21 public void setMemento(CarMemento memento) {
22 this.memento = memento;
23 }
24 }
4.3.3.7 Observer
4.3.3.7.1 BerkShire
01 package com.arnbe.patterns.behavioural.observer;
02
03 public class BerkShire implements Investor {
04
06
07 /**
08 * constructeur
09 * @param name
10 */
11 public BerkShire(String name) {

13 }
14
15 /*
16 * (non-Javadoc)
17 * @see com.arnbe.patterns.behavioural.observer.Investor#update(com.arnbe.patterns.behavioural.observer.Stock)
18 */
19 public void update(Stock stock) {
20 System.out.println("Notify : " + name + " of " + stock.getSymbol() + " change to " + stock.getPrice());
21 }
22 }
4.3.3.7.2 IBM
2
3 public class IBM extends Stock {
4
5 public IBM(String symbol, double price) {
6 super(symbol, price);
7 }
8 }
4.3.3.7.3 Investor
2
3 public interface Investor {
4
5 void update(Stock stock);
6 }
4.3.3.7.4 Sorros
02
03 public class Sorros implements Investor {
04
06
07 /**
08 * constructeur
09 * @param name
10 */
11 public Sorros(String name) {
13 }
14
15 /*
16 * (non-Javadoc)
17 * @see com.arnbe.patterns.behavioural.observer.Investor#update(com.arnbe.patterns.behavioural.observer.Stock)
18 */
19 public void update(Stock stock) {
20 System.out.println("Notify : " + name + " of " + stock.getSymbol() + " change to " + stock.getPrice());
21 }
22 }
4.3.3.7.5 Stock
02
04 import java.util.List;
05
06 public class Stock {
07
08 private List<Investor> investors = new ArrayList<Investor>();
09
10 protected String symbol;
11
12 protected double price;
13
14 /**
15 * constructeur
16 *
17 * @param price
18 * @param symbol
19 */
20 public Stock(String symbol, double price) {
21 super();
22 this.price = price;
23 this.symbol = symbol;
24 }
25
26 /**
27 * attache un observateur
28 *
29 * @param observer
30 */
31 public void attach(Investor observer) {
32 investors.add(observer);
33 }

34
35 /**
36 * détache un observateur
37 *
38 * @param observer
39 */
40 public void detach(Investor observer) {
41 investors.remove(observer);
42 }
43
44 /**
45 * notifie tous les observateurs
46 */
47 public void notifyObservers() {
48 for (Investor investor : investors) {
49 investor.update(this);
50 }
51 }
52
53 /**
54 * retourne le prix
55 * @return
56 */
57 public double getPrice() {
58 return price;
59 }
60
61 /**
62 * change le prix
63 * @param price
64 */
65 public void setPrice(double price) {
66 this.price = price;
67 notifyObservers();
68 }
69
70 /**
71 * retourne le nom de l'action
72 * @return
73 */
74 public String getSymbol() {
75 return symbol;
76 }
77 }
4.3.3.8 State
4.3.3.8.1 Agency
01 package com.arnbe.patterns.behavioural.state;
02
03 /**
04 * représente une agence
05 *
06 */
07 public class Agency {
08
10
11 /**
12 * constructeur
13 * @param name
14 */
15 public Agency(String name) {
16 super();
17 if(name==null) {
18 throw new IllegalArgumentException("name can't be null");
19 }
21 }
22
23 /**
24 * retourne le nom de l'agence
25 * @return
26 */
28 return name;
29 }
30
31 /* (non-Javadoc)
32 * @see java.lang.Object#equals(java.lang.Object)
33 */
34 @Override
35 public boolean equals(Object arg) {
36 if(arg instanceof Agency) {
37 return ((Agency)arg).getName().equals(name);
38 }
39 return false;
40 }
41
42 /* (non-Javadoc)
43 * @see java.lang.Object#hashCode()
44 */
45 @Override
46 public int hashCode() {
47 return name.hashCode();

48 }
49 }
4.3.3.8.2 Bank
02
05
06 /**
07 * représente une banque
08 *
09 */
10 public class Bank {
16 private List<Agency> agencies = null;
17
18 private BankState state = null;
19
21
22 /**
23 * constructeur
24 * @param name
25 */
26 public Bank(String name) {
27 super();
28 //état par défaut
29 this.state = new UnInitializeState(this);
30 // initialise la liste des agences
31 this.agencies = new ArrayList<Agency>();
32 setName(name);
33 }
34
35 /**
36 * ajoute une agence
37 * @param agency
38 */
39 public void addAgency(Agency agency) {
40 state.addAgency(agency);
41 }
42
43 /**
44 * supprime une agence
45 * @param agency
46 */
47 public void removeAgency(Agency agency) {
48 state.removeAgency(agency);
49 }
50
51 /**
52 * retourne le nom de l'état en cours
53 * @return
54 */
55 public String getStateName() {
56 return state.getStateName();
57 }
58
59 /**
61 * @return
62 */
64 return name;
65 }
66
67 /**
68 * affecte le nom de la banque
69 * @param name
70 */
71 public void setName(String name) {
72 state.setName(name);
73 }
74
75 /**
76 * définie l'état en cours
77 * @param state
78 */
79 void setState(BankState state) {
80 this.state = state;
81 }
82
83 /**
84 * retourne la liste des agences
85 * @return
86 */
87 List<Agency> getAgencies() {
88 return agencies;
89 }
90 }
4.3.3.8.3 BankState
02
03 /**

04 * Classe abstraite des états

05 */
06 public abstract class BankState {
07
08 protected Bank bank = null;
09
10 /**
12 * @param agency
13 */
14 public abstract void removeAgency(Agency agency);
15
16 /**
18 * @param agency
19 */
20 public abstract void addAgency(Agency agency);
21
22 /**
23 * retourne le nom de l'état
24 */
25 /*
26 * (non-Javadoc)
27 * @see com.arnbe.patterns.behavioural.state.BankState#getStateName()
28 */
29 public String getStateName() {
30 return getClass().getSimpleName();
31 }
32
33 /**
34 * change le nom de la banque
35 * @param name
36 */
37 public void setName(String name) {
38 if(name!=null) {
39 bank.setState(new InitializeState(bank));
40 } else {
41 bank.setState(new UnInitializeState(bank));
42 }
43 }
44 }
4.3.3.8.4 HaveAgencyState
02
03 /**
04 * Etat ou la banque a un nom et des agences
05 */
06
07 public class HaveAgencyState extends BankState {
08
09 /**
10 * constructeur
11 * @param bank
12 */
13 public HaveAgencyState(Bank bank) {
14 super();
15 if (bank == null) {
16 throw new IllegalArgumentException("Bank must be initilized");
17 }
18 this.bank = bank;
19 }
20
21 /*
22 * (non-Javadoc)
23 * @see com.arnbe.patterns.behavioural.state.BankState#removeAgency(com.arnbe.patterns.behavioural.state.Agency)
24 */
25 @Override
27 if (agency == null) {
28 throw new IllegalArgumentException("Agency can't be null");
29 }
30 if (!bank.getAgencies().contains(agency)) {
31 throw new IllegalArgumentException("can't delete unknown agency");
32 }
33 bank.getAgencies().remove(agency);
34 //si il ne reste plus d'agence on change d'état
35 if (bank.getAgencies().size() == 0) {
36 bank.setState(new InitializeState(bank));
37 }
38 }
39
40 /*
41 * (non-Javadoc)
42 * @see com.arnbe.patterns.behavioural.state.BankState#addAgency(com.arnbe.patterns.behavioural.state.Agency)
43 */
44 @Override
48 }
49 bank.getAgencies().add(agency);
50 }
51
52 }

4.3.3.8.5 InitializeState
02
03 /**
04 * La banque possède un nom mais pas d'agences
05 */
06 public class InitializeState extends BankState {
07
08 /**
09 * constructeur
10 * @param bank
11 */
12 public InitializeState(Bank bank) {
13 super();
16 }
18 }
19
20 /*
21 * (non-Javadoc)
23 */
24 @Override
26 throw new IllegalStateException("Add agency before remove");
27 }
28
29 /*
30 * (non-Javadoc)
32 */
33 @Override
37 }
38 bank.getAgencies().add(agency);
39 //changement d'état
40 bank.setState(new HaveAgencyState(bank));
41 }
42 }
4.3.3.8.6 UnInitializeState
02
03 /**
04 * Etat non initialisé de la banque
05 * elle ne possède pas de nom
06 * donc on ne peut ajouter des agences
07 */
08
09 public class UnInitializeState extends BankState {
10
11 /**
12 * constructeur
13 * @param bank
14 */
15 public UnInitializeState(Bank bank) {
16 super();
19 }
21 }
22
23 /*
24 * (non-Javadoc)
26 */
27 @Override
29 throw new IllegalStateException("Agency must be initialized before");
30 }
31
32 /*
33 * (non-Javadoc)
35 */
36 @Override
38 throw new IllegalStateException("Agency must be initialized before");
39 }
40 }
4.3.3.9 Strategy
4.3.3.9.1 InflateStrategy
01 package com.arnbe.patterns.behavioural.strategy;
02
03 import java.io.IOException;

04 import java.io.InputStream;
05 import java.io.OutputStream;
06
07 /**
08 * Interface des strategies
09 */
10 public interface InflateStrategy {
11
12 /**
13 * retourne le nom de l'algorythme
14 * @return
15 */
16 public abstract String getName();
17
18 /**
19 * conpresse le flux d'entrée vers le flux de sortie
20 * @param file
21 * @param in
22 * @param out
23 * @throws IOException
24 */
25 public abstract void inflate(String file, InputStream in, OutputStream out) throws IOException;
26 }
4.3.3.9.2 RarStrategy
02
06 public class RarStrategy implements InflateStrategy {
07
09 return "Rar";
10 }
11
12 public void inflate(String file, InputStream in, OutputStream out) throws IOException {
13 // code...
14
15 }
16
17 }
4.3.3.9.3 TarGunzipStrategy
02
06
07 public class TarGunzipStrategy implements InflateStrategy {
08
10 return "TarGunZip";
11 }
12
14 // code...
15
16 }
17
18 }
4.3.3.9.4 ZipStrategy
02
03 import java.io.File;
07 import java.util.zip.ZipEntry;
08 import java.util.zip.ZipOutputStream;
09
10 /**
11 * Implements an algorithm using the Strategy interface.
12 */
13
14 public class ZipStrategy implements InflateStrategy {
15
16 /*
17 * (non-Javadoc)
18 * @see com.arnbe.patterns.behavioural.strategy.InflateStrategy#getName()
19 */
21 return "Zip";
22 }
23
24 /*
25 * (non-Javadoc)
26 * @see com.arnbe.patterns.behavioural.strategy.InflateStrategy#inflate(java.lang.String, java.io.InputStream, java.io.OutputStream)
27 */

29 ZipOutputStream zOut = new ZipOutputStream(out);
30 zOut.putNextEntry(new ZipEntry(new File(file).getName()));
31 int c;
32 while((c = in.read()) != -1) {
33 zOut.write(c);
34 }
35 zOut.closeEntry();
36 zOut.close();
37 }
38 }
4.3.3.10 Template Method

4.3.3.10.1 DescSorter
01 package com.arnbe.patterns.behavioural.templatemethod;
02
03 /**
04 * Implements the primitive operations to carry out
05 * subclass-specific steps of the algorithm.
06 */
07
08 public class DescSorter extends Sorter {
09
10 /*
11 * (non-Javadoc)
12 * @see com.arnbe.patterns.behavioural.templatemethod.Sorter#compare(java.lang.String, java.lang.String)
13 */
14 @Override
15 public boolean compare(int item1, int item2) {
16 return item1 < item2;
17 }
18
19 /*
20 * (non-Javadoc)
21 * @see com.arnbe.patterns.behavioural.templatemethod.Sorter#getDescription()
22 */
23 @Override
24 public String getDescription() {
25 return "DescSorter";
26 }
27
28 }
4.3.3.10.2 Sorter
01 package com.arnbe.patterns.behavioural.templatemethod;
02
03 /**
04 * @role __TemplateContext
05 */
06
07 public abstract class Sorter {
08
09 /**
10 * méthode de comparaison
11 */
12 protected abstract boolean compare(int item1, int item2);
13
14 /**
15 * retourne la description du trieur
16 */
17 public abstract String getDescription();
18
19 /**
20 * tri le tableau d'entier
21 */
22 public void sort(int[] ints) {
23 for (int i = 0; i < (ints.length - 1); i++) {
24 if(compare(ints[i], ints[i+1])) {
25 //permutation
26 int tmp = ints[i];
27 ints[i] = ints[i+1];
28 ints[i+1] = tmp;
29 }
30 }
31 }
32 }
4.3.3.11 Visitor
4.3.3.11.1 Agency
01 package com.arnbe.patterns.behavioural.visitor;
02 /**
03 * représente une agence
04 *
05 */
06 public class Agency {
07
09
10 /**

11 * constructeur
12 * @param name
13 */
14 public Agency(String name) {
15 super();
17 }
18
19 /**
21 * @return
22 */
24 return name;
25 }
26
27 /* (non-Javadoc)
28 * @see java.lang.Object#equals(java.lang.Object)
29 */
30 @Override
31 public boolean equals(Object arg) {
32 if (arg instanceof Agency) {
33 return ((Agency) arg).getName().equals(name);
34 }
35 return false;
36 }
37
38 /* (non-Javadoc)
39 * @see java.lang.Object#hashCode()
40 */
41 @Override
42 public int hashCode() {
43 return name.hashCode();
44 }
45 }
4.3.3.11.2 Bank
02
05
06 /**
07 * représente une banque
08 *
09 */
10 public class Bank implements Element {
11
12 protected List<Agency> agencies = null;
13
14 protected String name = null;
15
16 /**
17 * constructeur
18 *
19 * @param name
20 */
21 public Bank(String name) {
22 super();
23 // initialise la liste des agences
24 this.agencies = new ArrayList<Agency>();
26 }
27
28 /**
30 *
31 * @param agency
32 */
34 agencies.add(agency);
35 }
36
37 /**
39 *
40 * @param agency
41 */
43 agencies.remove(agency);
44 }
45
46 /**
48 *
49 * @return
50 */
52 return name;
53 }
54
55 /**
56 * @return
57 */
58 protected List<Agency> getAgencies() {
59 return agencies;
60 }

61
62 /*
63 * (non-Javadoc)
64 * @see com.arnbe.patterns.behavioural.visitor.Element#accept(com.arnbe.patterns.behavioural.visitor.BankVisitor)
65 */
66 public void accept(BankVisitor visitor) {
67 visitor.visit(this);
68 }
69 }
4.3.3.11.3 BankVisitor
02
03 /**
04 * interface visiteur
05 */
06 public interface BankVisitor {
07
08 /**
09 * méthode de visite pour l'élément Bank
10 */
11 void visit(Bank element);
12 }
4.3.3.11.4 CSVBankVisitor
02
03 /**
04 * classe générant du CSV à partir d'un objet banque
05 *
06 */
07 public class CSVBankVisitor implements BankVisitor {
08
09 /*
10 * (non-Javadoc)
11 * @see com.arnbe.patterns.behavioural.visitor.BankVisitor#visit(com.arnbe.patterns.behavioural.visitor.Bank)
12 */
13 public void visit(Bank bank) {
14 StringBuffer buf = new StringBuffer();
15
16 for (Agency agency : bank.getAgencies()) {
17 buf.append(bank.getName())
18 .append(';')
19 .append(agency.getName())
20 .append('\n');
21 }
22
23 System.out.println(buf.toString());
24 }
25 }
4.3.3.11.5 Element
2
3 public interface Element {
4
5 /**
6 * accept un visiteur
7 */
8 void accept(BankVisitor visitor);
9 }
4.3.3.11.6 XMLBankVisitor
02
03 /**
04 * classe générant du XML à partir d'un objet banque
05 *
06 */
07 public class XMLBankVisitor implements BankVisitor {
08
09 /*
10 * (non-Javadoc)
11 * @see com.arnbe.patterns.behavioural.visitor.BankVisitor#visit(com.arnbe.patterns.behavioural.visitor.Bank)
12 */
13 public void visit(Bank bank) {
14 StringBuffer buf = new StringBuffer();
15 buf.append("<bank name=\"")
16 .append(bank.getName())
17 .append("\">\n");
18
19 for (Agency agency : bank.getAgencies()) {
20 buf.append(" <agency name=\"")
21 .append(agency.getName())
22 .append("\"/>\n");
23 }
24
25 buf.append("</bank>");

26 System.out.println(buf.toString());
27 }
28 }

5 L’AUTEUR
Nom : BARBE
Prénom : Arnaud
Email : arnaud.barbe@free.fr
PROFIL GENERAL
Accompagnement et encadrement d’équipes de développement.

Analyse et conception de cahiers des charges.
Etudes techniques et définition d’architecture I-NET.
Réalisation d’études préalables et qualification de produits et solutions techniques.
Réponse à appel d’offre.
Rédaction de documents techniques.
Réalisation de projets, sites et portails Internet.
PROFIL TECHNIQUE
Expert java/JEE (7 ans d’expérience).

Forte connaissance des principaux serveurs d’applications du marché (Websphere,
Weblogic, JBoss, Jonas, Borland Enterprise Server).
Bonne connaissance des micros containers (HiveMind).
Forte connaissance des systèmes ORM (Hibernate, JDO, DAO, …) et des bases de
données (Oracle, DB2, MySQL).
Forte connaissance des Design Patterns et Patterns JEE.
Veille technologique continu.
Expertise technique.
Sensible à l’approche XP.

Java Entreprise Et Les Design Patterns 2 0 2007 French

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Java Entreprise Et Les Design Patterns 2 0 2007 French

Uploaded by

Copyright:

Available Formats

Java entreprise et les design

Arnaud BARBE Page 1 sur 109

2.7.3.6 FlyWeight 34

3.1 CODE SOURCE 64

Arnaud BARBE 3 / 109

Arnaud BARBE 4 / 109

4.3.3.8 State 100

Arnaud BARBE 5 / 109

Arnaud BARBE 6 / 109

Arnaud BARBE 7 / 109

2.5 General Responsability Assignement Software

Arnaud BARBE 8 / 109

07 int result = add.getFirstOp() + add.getSecondOp();

Il serait plus correct d’écrire :

2.5.2.2 Low coupling

Figure 2 Couplage plus faible

2.5.2.3 High cohesion

Figure 3 Exemple de faible cohésion

Dans cet exemple, la classe Customer doit endosser la responsabilité de l’affichage

Figure 4 Attention à une trop forte cohésion !!

Figure 5 Répartition de la responsabilité de création

Arnaud BARBE 11 / 109

Facade Controller : point d’entrée unique vers un système ou sous système.

Figure 6 Limitation du couplage par utilisation d’un Controller

Arnaud BARBE 12 / 109

Figure 7 Exemple de polymorphisme

2.5.3.3 Pure Fabrication

Figure 8 Classe faiblement cohésive

Figure 9 Délégation de responsabilité

Arnaud BARBE 13 / 109

Figure 10 L'Adapter reduit le couplage

2.5.3.5 Law of Demeter

Externalisation de certaines valeurs dans des fichiers de propriétés.

D’ailleurs beaucoup de designs patterns et de principes de programmation vont dans ce sens.

Arnaud BARBE 14 / 109

2.6 Design principles

Gestion des évolutions et des dépendances entre classes.

2.6.2Gestion des évolutions et des dépendances entre classes

Figure 11 Limitation de la variation logicielle par utilisation de l'héritage

Ce motif s’applique naturellement si certains principes de bon sens sont respectés :

Arnaud BARBE 15 / 109

2.6.2.2 Liskov substitution principle

Figure 12 Substitution possible entre les différentes implémentations

2.6.2.3 Dependency inversion principle

Figure 13 Un couplage fort nuit à la réutilisation

Figure 14 Réutilisation plus aisé

Couplage faible : seul les interfaces sont connus.

2.6.2.4 Interface segregation principle

Figure 15 Trop de fonctionnalités proposées…

…il convient de répartir les services dans plusieurs classes.

Arnaud BARBE 17 / 109

Figure 16 Répartition plus homogène

2.6.3Organisation de l’application en modules

Figure 17 Utilisation du pattern DAO

Arnaud BARBE 18 / 109

Figure 18 Utilisation d'un ORM

Figure 19 Utilisation conjointe : ORM + DAO

2.6.3.2 Common reuse principle

2.6.3.3 Common closure principle

Arnaud BARBE 19 / 109

2.6.4Gestion de la stabilité de l’application

Figure 20 Dépendance cyclique

2.6.4.2 Stable dependencies principle