2004 Les Design Patterns en OO

Les design patterns en programmation orientée objet
CNAM - Génie Logiciel

Année 2004-2005
Cédric Lelong
Sommaire
1 LES DESIGN PATTERNS ET LA CONCEPTION ORIENTEE OBJET ........................................ 4

1.1 LES DESIGN PATTERNS DANS L’HISTOIRE .................................................................................... 4
1.2 QUE SONT LES DESIGN PATTERNS ? .......................................................................................... 5
2 LE CATALOGUE DE PATTERNS DU GANG OF FOUR.............................................................. 6

2.1 DESIGN PATTERNS: ELEMENTS OF REUSABLE OBJECT-ORIENTED SOFTWARE ............................ 6
2.2 PRESENTER UN DESIGN PATTERN ? ........................................................................................... 7
2.3 LE DESIGN PATTERN SINGLETON : FAUT-IL DONNER UNE IMPLEMENTATION DU DESIGN PATTERN ? 8
2.3.1 Le design pattern Singleton ............................................................................................... 8
2.3.2 Implémentation et problème du multithread ...................................................................... 9
2.3.3 Faut-il proposer une implémentation d’un design pattern ? .............................................. 9
3 DESIGN PATTERN MODELE VUE CONTROLEUR : 3 PATTERN EN 1 ! ................................ 11

3.1 LE PATTERN MODEL-VUE-CONTROLEUR .................................................................................. 11
3.2 LE PATTERN OBSERVATEUR ET LE MODELE MVC ..................................................................... 12
3.3 DESIGN PATTERN COMPOSITE ................................................................................................. 14
4 LE CATALOGUE DES PATTERNS GRASP............................................................................... 15

4.1 LES GRASP .......................................................................................................................... 15
4.2 QUATRE GRASP ................................................................................................................... 15
4.2.1 Le pattern Expert ............................................................................................................. 15
4.2.2 Le pattern Créateur.......................................................................................................... 15
4.2.3 Le pattern Faible couplage .............................................................................................. 15
4.2.4 Le pattern Forte Cohésion ............................................................................................... 16
4.3 UN EXEMPLE D’APPLICATION DES GRASP PATTERNS ............................................................... 16
4.3.1 Pattern Expert .................................................................................................................. 16
4.3.2 Pattern Créateur .............................................................................................................. 16
4.3.3 Pattern faible couplage .................................................................................................... 16
4.4 LES GRASP, DES DESIGN PATTERNS ? ................................................................................... 17
5 SYNTHESE & CONCLUSION...................................................................................................... 18
6 URLOGRAPHIE ........................................................................................................................... 19
7 BIBLIOGRAPHIE ......................................................................................................................... 20
8 GLOSSAIRE DES SIGLES .......................................................................................................... 20
- Les design patterns en programmation orientée objet -

3
1 Les design patterns et la conception orientée objet
1.1 Les design patterns dans l’histoire
Les premiers concepts de la Programmation Orientée Objet [POO] apparaissent au cours

des années 70 dans le langage Simula, pour trouver un essor majeur dans les années 80
avec des langages tels que Smalltalk, C++ et Eiffel. Un des objectifs cette technique de
programmation est de permettre une meilleure réutilisation des développements antérieurs.
La POO se combine en phase de conception avec des langages de modélisation permettant

de préciser une architecture du logiciel à développer avant d’en aborder le codage. UML est
sans doute le représentant le plus largement répandu aujourd’hui de ces langages de
modélisation.
La combinaison de la POO et des Langages de modélisation conduit naturellement à franchir

une nouvelle étape : Le développement de « modèles » génériques applicables à la
programmation orientée objet. Ces modèles, les design patterns, ou « modèle de
conception » doivent permettre de capitaliser l’expérience accumulée lors de
développements précédant.
L’origine des design pattern se retrouve dans les travaux d’un architecte en batiment du nom
de Christopher Alexander, qui publie deux livre en 1970: A Pattern Language et A Timeless
Way of Building. Dans ces ouvrages, C. Alexander développe une nouvelle approche de
l’architecture, basée sur l’intuition qu’un ensemble de règles générales peuvent définir tout
aussi bien la structure d’une ville, d’une maison ou même d’une simple pièce. Etonnement,
ses théories auront finalement certainement plus d’impact dans le domaine de l’Informatique
que de l’architecture.
L’intérêt pour les design patterns en informatique reste très discret jusqu’en 1987, année où
il fait surface lors d’une des conférence annuelle « Object-Oriented Programming, Systems,
Languages & Applications » [OOPSLA]. Dès lors, beaucoup de publications traitent du sujet.
L’une d’elle, Design Patterns: Elements of Reusable Object-Oriented Software, parue en
1995, s’impose très rapidement comme l’un des ouvrages de référence traitant des design
patterns.

4
1.2 Que sont les design patterns ?
Définition de Christopher Alexander :
“A pattern is a careful description of a perennial solution to a recurring problem within

a building context, describing one of the configurations which brings life to a building.
A pattern language is a network of patterns that call upon one another. An individual
house might, for example, call upon the patterns described under the names of half-
hidden garden, light from two sides in every room, variation of ceiling height, bed
alcove, etc. Patterns help us remember insights and knowledge about design and can
be used in combination to create designs.” – Un pattern est une description méticuleuse
d’une solution pérenne à un problème récurrent dans un contexte particulier. Il présente une
des briques qui donnent la vie à un édifice. Un langage de pattern est un réseau de patterns
utilisables conjointement. Une maison individuelle, par exemple, peut requérir les patterns
nommés jardin semi ombragé, éclairage des pièces par les deux côtés, variation de la
hauteur de plafond, alcove, etc. Les patterns nous aident à conserver perspicacité et
connaissances en design, leur combinaison nous permet de définir un design.
Description extraite de Design Patterns: Elements of Reusable Object-Oriented :

“The design patterns in this book are descriptions of communicating objects and classes that
are customized to solve a general design problem in a particular context.”- Les design
patterns dans ce livre sont une description d’objets et de classes communicantes qui sont
adaptées pour résoudre un problème général de design dans un contexte particulier
Ces deux définitions le font bien ressortir, les design patterns sont avant tout un outil,
d’expression d’une expérience de programmeur. Partant du postulat qu’un informaticien sera
amené dans son quotidien professionnel, à rencontrer de façon récurrente un certain nombre
de situations génériques, les design patterns permettent de nommer et étudier cette situation
pour tacher d’en retirer une expérience réutilisable. En se plaçant à un niveau d’abstraction
suffisant, il est en effet possible de définir une solution possible à un problème générique de
conception, dans un contexte donné. La question du « comment vais-je résoudre ce
problème » devient alors « comment vais résoudre ce problème cette fois ci ».
Les design patterns constituent également un outil de communication entre programmeurs.

Une situation étant nommée puis décrite, il est alors possible d’échanger à son propos. Par
extension, les design patterns deviennent un excellent support pour la transmission de
l’expérience accumulée aux jeunes informaticiens.

5
2 Le catalogue de patterns du gang of four
2.1 Design Patterns: Elements of Reusable Object-Oriented Software
Un des ouvrage largement reconnu comme central dans le domaine des design patterns est
le livre “ Design Patterns: Elements of Reusable Object-Oriented Software ” coécrit par Erich
Gamma, Richard Helm, Ralph Johnson et John Vlissides, surnommés le Gang Of Four
[GOF]. Cet ouvrage définit une méthodologie de description de patterns et un « catalogue »
de 23 d’entre eux. Comme le précisent ses auteurs, ce livre « ne fait que documenter des
designs existants ». Mais l’objectif est en fait beaucoup plus ambitieux : « lancer un
mouvement de documentation de l’expertise des informaticiens ».
Le Gang Of Four propose un regroupement des patterns en 3 catégories par objectif :
1. Les Creational Patterns : ces patterns ont pour but de permettre une abstraction du
processus d’instanciation d’un objet.
2. Les Structural Patterns : ces patterns proposent des modèles de composition

d’objets
3. Les Behavioral Patterns : Ils traitent du comportement des objets lors de l’exécution
du programme.
Une « portée » [scope] est aussi attribuée à chaque pattern, précisant si le modèle
s’applique à l’architecture des classes ou à l’organisation des objets.
Le catalogue de design patterns est donc finalement présenté comme suit :
Champ d’application
Creational Structural Behavioral

Classe Factory Method Adapter Interpreter
Template Method
Objet Abstract Factory Adapter Chain of Responsibility
Builder Bridge Command
Scope Prototype Composite Iterator
(portée) d Singleton Decorator Mediator
Facade Memento
Proxy Flyweight
Observer
State
Strategy
Visitor

6
2.2 Présenter un design pattern ?
Cette question si elle se réfère à la forme plus qu’au fond du sujet est pourtant bien centrale.
En effet, plus on rentre dans le sujet des design patterns plus il devient évident qu’au delà
d’un outil technique, les modèles de conceptions sont avant tout un outil de communication
au sein d’un projet.
Le GOF propose donc de donner à un pattern une définition comportant au moins ces 4
points :
Un nom : Nommer un modèle de conception est la première étape. Elle va permettre un

échange autour d’un concept nommé. Les noms donnés aux patterns montrent bien la
diversité de leurs usages. Certains ont des noms mathématiques (Singleton), d’autre tiré du
monde du bâtiment (pont, facade…)
Un objectif à atteindre : Il est la raison d’être du pattern. Il peut s’agir de la résolution d’un
problème d’algorithmique ou plus largement d’un problème architectural, voire d’une liste de
conditions conditionnant l’utilisation du pattern
Une Solution : La solution doit être aussi générique que possible. En effet, il est impensable
de définir une méthode de résolution à la fois très précise et pourtant applicable à un très
grand nombre de cas. Dans ce domaine, la solution sera souvent exprimée sous forme d’un
diagramme de classe UML, permettant ainsi un niveau d’abstraction naturel par rapport au
langage utilisable.
Des conséquences : Le choix d’utilisation d’un pattern n’est pas anodin. Il va entraîner la
résolution d’un problème de conception mais ne comportera pas seulement des avantages.
Ainsi, si l’utilisation d’un pattern se traduit en général par une meilleure évolutivité, et
réutilisabilité du développement, elle peut aussi induire une perte de performance du code
en temps ou espace mémoire.
Cette structure de présentation des design patterns a été largement adoptées dans la
littérature. Elle est toutefois parfois complétée par d’autres qualificatifs :
• Un contexte : permettra de spécifier le champs d’application du pattern, la liste des

conditions nécessaires à sa validité (sortie par conséquent du paragraphe objectif)
• Une implémentation : un exemple de code mettant en œuvre le pattern. Si cet

élément est intéressant en terme de compréhension, il est toutefois largement
critiqué, car il tend à lier un pattern à un langage précis. Nous détaillerons ce
problème au paragraphe suivant.

7
2.3 Le design pattern Singleton : Faut-il donner une implémentation du design
pattern ?
2.3.1 Le design pattern Singleton

Le premier exemple de pattern du GOF est généralement le pattern singleton. Ce pattern se
caractérise par une énoncée simple de la problématique à résoudre, et par une solution
possédant une structure simple.
Nom Singleton
Objectif On souhaite s’assurer qu’une classe ne peut être instanciée qu’une seule
et unique fois (ou par extension, un nombre de fois contrôlé) et offrir un
point d’accès à cette instanciation.
Solution
L’astuce de ce pattern est d’instancier l’objet dont on veut éviter la

duplication en temps qu’attribut de classe. Il est alors possible de confier
l’instanciation du Singleton à une méthode de classe. Elle sera seule à
pouvoir appeler son constructeur privé, et pourra donc être garante de
l’unicité du singleton.
Conséquences • Permet de contrôler les accès à une instance, grâce à
l’encapsulation de son instanciation unique
• Permet de réduire l’espace de nom, en évitant le recours à des
variables globales pour stocker des instances uniques.
• Plus flexible que le recours à des attributs et méthodes de classe
(qui aurait également permis de résoudre le problème) :
o Il est aisé de faire varier le nombre d’instanciation maximal
en modifiant la méthode Instance()
o Il est possible d’étendre la classe Singleton.

8
2.3.2 Implémentation et problème du multithread
Pour détailler encore le pattern Singleton, nous pourrions par exemple nous intéresser à son
implémentation. Ci-dessous, une implémentation possible en java :
import java.util.* ;
class Singleton{
private static Singleton instance;
private List maList;
private boolean etat;
private Singleton(){
maList= new ArrayList();
etat = true;
}
public static Singleton Instance(){
if (instance==null) //1
instance=new Singleton(); //2
return instance; //3
}
}
Il est intéressant de remarquer que cette solution fonctionne parfaitement en environnement

monothread, mais peut se révéler être fausse en environnement multithread.
En effet, le scénario suivant pourrait se produire en multhread :
Thread 1 appelle Instance() et détermine que instance est null en ligne //1
Thread 1 entre dans le bloc if puis est préempté par le thread 2 avant l'exécution de la ligne //2
Thread 2 appelle Instance() et détermine que instance est null en ligne //1
Thread 2 entre dans le bloc if, crée un nouveau Singleton et assigne ce nouvel objet à la
variable instance en ligne //2
Thread 2 retourne la référence au Singleton en ligne 3
Thread 2 est préempté par le Thread 1
Thread 1 reprend où il s'était arrêté et exécute la ligne //2 créant alors une autre instance de
Singleton
Thread 1 retourne cette nouvelle instance en ligne //3
On trouve dans divers articles les solutions suivantes à ce problème :

• Synchroniser toute la méthode Instance()
• Utiliser ThreadLocal : Une variable ThreadLocal est une variable qui a une copie
différente pour chacun des threads qui l' utilisent. Chaque thread peut manipuler sa
version de la variable indépendamment des autres threads et, en réalité, ignore
complètement la valeur de cette variable dans les autres threads. La classe
ThreadLocal présente trois méthodes
• Abandonner la synchronisation et utiliser un initialiseur static
On le voit, ces solutions sont très spécifiques à java.
2.3.3 Faut-il proposer une implémentation d’un design pattern ?

Cet exemple le montre bien, le fait de donner un exemple d’implémentation d’un pattern peut
être problématique. En effet, il soulève dans notre exemple un ensemble de
questionnements nouveaux, de problématiques qui ne pourront être résolues qu’avec des
outils propres à un langage particulier. On s’éloigne ainsi de l’impératif de généricité
maximale du design pattern.

9
Pourtant le problème soulevé par cette implémentation ne peut être ignoré. Pour être
complet, notre design pattern devra donc comporter une mention sur cet aspect, par
exemple dans un paragraphe contexte, ou dans la liste des conséquences.

10
3 Design pattern Modèle Vue Contrôleur : 3 pattern en 1 !
3.1 Le pattern Model-Vue-Controleur
Le modèle MVC (Modèle Vue Contrôleur) est un modèle de conception d' interfaces très
répandu. Il a été créé dans les années 1980 pour Smalltalk-80. Il a été recommandé par Sun
pour la plate-forme de développement J2EE. Le modèle MVC représente un complément fort
utile aux outils du développeur, quel que soit le langage utilisé. Ce modèle d' architecture
impose la séparation entre les données, les traitements et la présentation, ce qui donne trois
parties fondamentales dans l' application finale : le modèle, la vue et le contrôleur.
Le modèle MVC peut être décrit sous la forme du modèle de conception suivant :
Nom Model Vue Controleur, MVC, Model view controller (US)

Contexte Les applications Web se caractérisent par des contraintes
particulières : Les applications sont ouvertes et accessibles par une
large gamme d’utilisateurs qui varient par leurs besoins IHM (client
léger pour un internaute, client riche pour un administrateur,
périphériques d’accès nouveaux comme les PDA, téléphones
portables…)
Objectifs • Rendre un composant métier non dépendant de son IHM
• Rendre un composant métier accessible par plusieurs IHM
Solution
Schéma
extrait
de :
http://jav
a.sun.co
m/bluepr
ints/patte
rns/MVC
-
detailed.
html
Le modèle représente le comportement de l' application : traitements

des données, interactions avec la base de données, etc. Les résultats
renvoyés par le modèle sont dénués de toute présentation, et sont
présentés par les vues. Plusieurs vues peuvent afficher les
informations d'
un même modèle.
La vue correspond à l' interface avec laquelle l'

utilisateur interagit. Elle
peut être conçue en html, ou tout autre « langage » de présentation. La
vue n'effectue aucun traitement, elle se contente d' afficher les résultats

11
des traitements effectués par le modèle, et de permettre à l'
utilisateur
d'
interagir avec elles.
Le contrôleur analyse la requête du client et appelle le modèle et la

vue correspondants à la demande. Il n' effectue aucun traitement, ne
modifie aucune donnée mais se contente d' appeler le modèle adéquat
et de renvoyer la vue correspondant à la demande.
Conséquences • Le faible couplage entre les composants du modèle implique

que :
o Les composants constituant le modèle sont réutilisables.
o L’application développée sur le modèle MVC est plus
facilement maintenable car ses composants peuvent
être mis à jour séparément.
• Le modèle implique par contre une complexité de modélisation
et se traduit par un plus grand nombre de classes
Le pattern MVC correspond un niveau de détail de conception faible. En augmentant ce

niveau de détail, on s’aperçoit que plusieurs patterns du GOF peuvent s’intégrer dans ce
« macro pattern ».
3.2 Le pattern Observateur et le modèle MVC
Un premier pattern à intervenir dans le modèle MVC est le pattern Observateur :
Nom observateur, observer (US)

Objectif définir une dépendance (1..N) entre des objets de façon à ce que
lorsqu’un objet change d’état, tous objets utilisant l’objet modifié soient
mis à jour automatiquement
Ceci est utile lorsque :

• Deux objets dépendants l’un de l’autre peuvent être modifiés
(mis à jour) indépendamment.
• Le changement de l’état d’un objet doit se répercuter à un
nombre indéterminé d’objets
• Un objet doit notifier à d’autres objets un changement d’état
sans faire d’hypothèse sur la nature de ces objets.

12
Solution
l’idée de ce pattern est de casser une dépendance réciproque entre

deux objets, l’un sujet et l’autre observateur, en plaçant une
dépendance dans un sens entre deux interfaces et une dépendance
dans l’autre sens entre les objets implémentant ces interfaces.
Conséquences Le maintient de la cohérence d’une application est facilité sans mettre

en place un couplage fort entre deux classes dépendantes ce qui
limiterait la réutilisation de ces classes.
Le pattern observateur et le modèle MVC

Le pattern observateur peut s’appliquer directement au niveau des liaisons Vue - Contrôleur
et Vue - Modèle. Ses conséquences vont tout à fait dans le sens des objectifs de réutilisation
et de maintenabilité visés par le modèle MVC.

13
3.3 Design pattern composite
Un autre design pattern souvent rencontré dans l’implémentation du modèle MVC est le
pattern composite.
Nom Composite
Objectif • Permettre à une classe de composer et d’utiliser de façon simple
(cohérente, unique) une hiérarchie complexe d’objets
Solution
Conséquences • Le client peut utiliser sans différence un composite, c'

est-à-dire un
ensemble d’objets, ou une feuille
• Il sera facile par dérivation de la classe Feuille d’ajouter de
nouveaux types de composants sans avoir à modifier le client
• Peut induire un design trop généraliste. Il sera ainsi difficile de
limiter l’ajout de certains type de composant car la notion de type
d’objet n’est pas utilisée par la méthode Ajoute().
Le pattern composite et le modèle MVC

Le pattern composite pourra être utilisé dans le modèle MVC, pour améliorer le composant
Vue.
Dans un contexte de développement d’un application Web, la vue gèrera la composition d’un
page Web. On peut remarquer que cette page Web est en fait une composition générée
dynamiquement selon les actions de l’utilisateur. Cette composition si elle est idéalement
différente pour chaque requête de l’utilisateur, repose en général sur un ensemble
d’éléments récurrents (arborescence de navigation, barre horizontale haute, pied de page,
affichage d’une publicité…)
Dans le modèle MVC, le pattern composite pourra alors être judicieusement utilisé pour
réaliser cette composition en permettant d’assembler des éléments communs en une page à
la demande du contrôleur.

14
4 Le catalogue des patterns GRASP
4.1 Les GRASP

Les GRASP sont une autre contribution importante sur la thématique des modèles de
conception. Introduit par Craig Larman, les GRASP pattern, pour General Responsability
Assignement Software Patterns, représentent des notions plus généralistes que celles
introduites par le GOF. Ainsi leur étude présente une nouvelle vision de ce que peut être un
design pattern.
4.2 Quatre GRASP

Nous allons dans un premier temps détailler quelques GRASP. Nous en étudierons
l’application dans le paragraphe 4.3.
4.2.1 Le pattern Expert

Contexte :
Dans le cycle de développement d’un logiciel, les étapes préliminaires de conception
peuvent très rapidement conduire à définir un très grand nombre de classes. Cette multitude
induit une complexité dans le choix de l’affectation des responsabilités aux classes.
Objectif :
Affecter au mieux une responsabilité à une classe
Solution :
Affecter à une classe les responsabilités correspondantes aux informations dont elle dispose
intrinsèquement ou par le biais d’objets de collaboration
4.2.2 Le pattern Créateur

Objectif :
Affecter la responsabilité de créer un Objet.
Solution :
Si une classe A
• agrège des instances de la classe B
• contient des instances de la classe B
• utilise des instances de la classe B
• possède les données nécessaires à l’instanciation de la classe B
Alors la responsabilité de l’instanciation de la classe B doit être confiée à A.
Remarque :
Si B est une classe non triviale, il est recommandé de laisser son instanciation à une classe
annexe. Ce principe est notamment mis en application dans le pattern factory du GOF.
4.2.3 Le pattern Faible couplage

Objectif :
• Faciliter la maintenance d’un logiciel
• Favoriser la réutilisation du code
Solution :
• Réduire au maximum les dépendances entre les classes
Remarque :
Le faible couplage ne doit pas être suivi comme un dogme : En effet, poussé à l’extrême, le
pattern de faible couplage – Toutes les classes sont indépendantes – va a l’encontre du
paradigme de la programmation orienté objet qui veut qu’un logiciel soit un ensemble
d’objets connectés et communicants les uns avec les autres.

15
4.2.4 Le pattern Forte Cohésion
Objectif :
Favoriser la maintenabilité, réutilisation et compréhension du code.
Solution :
Regrouper au sein d’une même classe des responsabilités cohérentes, c’est à dire
spécialisées dans un domaine commun. On réduit ainsi la complexité du code.
Spécialiser au maximum chaque responsabilité.
4.3 Un exemple d’application des GRASP patterns

Nous allons illustrer l’usage des patterns GRASP au travers d’un exemple simpliste :
imaginons que dans une application, nous ayons besoin de modéliser la notion de livre.
4.3.1 Pattern Expert

Une question pourrait être de se demander à qui attribuer la responsabilité de compter le
nombre de page du livre. Intuitivement, on aura tendance à attribuer cette responsabilité à
l’objet livre. Cependant, il faudra prendre en compte le fait que le livre est composé de
plusieurs chapitres qui sont composés à leur tour de plusieurs pages. Le pattern expert nous
recommandera alors de donner une responsabilité de sous comptage à l’objet chapitre.
4.3.2 Pattern Créateur

La question dans notre application va être de savoir qui crée l’objet page ? L’objet chapitre ?
L’application du pattern créateur nous recommande de confier cette responsabilité à l’objet
utilisant l’objet à créer. Dans notre exemple, nous obtenons donc :
4.3.3 Pattern faible couplage

Nous avons intuitivement dans cet exemple mis en place une structure de classe impliquant
un faible couplage. Cependant, nous en voyons rapidement un des désavantage : nous
obtenons deux classes, Livre et Chapitre, qui, dans notre modèle simple se révèlent très
similaires, voire redondantes. L’application du pattern « Composite » du GOF, étudié
précédemment, nous permettrait en effet de supprimer cette redondance :

16
Bien qu’induisant un fort couplage entre nos composants, ce pattern nous apporte une
flexibilité nouvelle qui nous permettrait de sectionner un livre en autant de niveau de que
souhaité, tout en gardant une grande simplicité de comptage de page par niveau et en
assurant une non redondance du code. Il parait donc adapté à notre exemple.
4.4 Les GRASP, des design patterns ?

A l’étude de certains des design patterns GRASP les plus généraux, on peut se demander
s’il on traite toujours de modèles de conception ou plutôt de principes de conception de
design patterns.
Les GRASP se distinguent en effet des patterns GOF par un niveau de généralité supérieur.
Certains diront que ces patterns sont intuitifs et appliqués de façon inconsciente par tout
développeur expérimenté. Pour un développeur « objet » débutant, ces patterns gardent
cependant réel un intérêt : ils fournissent en effet un ensemble de règles très générales et
non absolues, des principes pour s’approcher des idéaux de la programmation objet, à
savoir maintenabilité, réutilisation, clarté du code.

17
5 Synthèse & Conclusion
Les design patterns appliqués à la programmation orientée objet représentent le carrefour de

nombreux champs de compétences de l’informaticien.
Ils sont au premier abord un outil très puissant de conception. Ils apportent en effet une
partie de la matière première nécessaire à l’élaboration d’une architecture logicielle en
fournissant une base d’exemples éprouvés et récurrents, commentés dans leurs avantages
et inconvénients pour résoudre un problème de conception général. Mais ils sont surtout un
extraordinaire outils de communication projet : Ils permettent en effet de définir un langage
commun à une équipe, de nommer des concepts, de les discuter. Ils sont ainsi un outil
efficace de capitalisation et de transmission d’une expérience acquise sur un projet. Celle-ci
sera d’autant plus réutilisable qu’elle est découplée d’un quelconque langage.
Le concept de design pattern peut être utilisé à divers niveau : Il couvre certes des modèles
d’organisation de classes résolvant des problèmes précis. C’est par exemple le cas des
patterns du catalogue défini par le Gang Of Four. Mais certains utilisent aussi le terme de
design pattern pour décrire une architecture globale, le pattern MVC en est un exemple.
Enfin, les GRASP nous montrent qu’il est même possible d’utiliser le formalisme « pattern »
pour énoncer des principes généraux de programmation.
L’analyse des design patterns peut se révéler complexe pour un développeur débutant. Elle
nécessite en effet un haut niveau de compréhension des concepts de la programmation
orientée objet, et une maîtrise avancée d’UML. D’autre part, la représentation des design
patterns correspond à un tel niveau de synthétisation de la culture de la conception en
orienté objet, que l’ensemble des tenants et aboutissants d’un pattern ne sont jamais aisés à
appréhender.
Mais cette complexité correspond aussi à la puissance des patterns. Quelle force de pouvoir
détenir un outil à la fois pont entre divers activité du génie logiciel : la conception, la
conception détaillée, la modélisation, la programmation… et permettant d’acquérir des
repères résultants d’une culture collective de la programmation orientée objet !
Au final, cet exposé m’aura permis de réaliser une première approche du concept des design
patterns en orienté objet. Il appelle une réflexion plus exhaustive sur l’ensemble des patterns
non abordés ici, et également plus poussée sur l’application souhaitable ou non de chaque
pattern proposé.

18
6 URLographie
Cet exposé est largement basé sur des ressources trouvées sur Internet. Voici une courte
liste des plus utilisées :
http://www-eleves-isia.cma.fr/documentation/DesignPatterns/
Version HTML du livre « Design Pattern » par Erich Gamma, Richard Helm, Ralph Johnson
et John Vlissides surnommé « Gang Of Four ».
Cette ouvrage est l’œuvre centrale dans le domaine des design patterns. Elle définit un
formalisme de description des patterns et propose un catalogue de 23 design patterns
récurrents.
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/DEA2e
TOC.html
Pet store - Designing Enterprise Applications with the J2EETM Platform, Second Edition.
Une étude complète de la conception d’une application de ecommerce, le fameux PetStorte,
basée sur un modèle à 3 couches implémenté en java. Cette étude met en avant de
nombreux patterns.
http://www.dofactory.com/patterns/patterns.aspx
Une liste complète et synthétique des 23 patterns du GOF
http://wpetrus.developpez.com/uml/grasp/grasp.pdf
Introduction aux patterns GRASP par Pierre Chauvin
www.wikipedia.org
Un projet de construction collective d’une encyclopédie gratuite. Un bon point de départ pour
tout étude.
http://perso-info.enst-bretagne.fr/~beugnard/cours/DP.pdf
Cours sur les design patterns par A. Beugnard
http://www.math.utsa.edu/sphere/salingar/Chris.text.html
SOME NOTES ON CHRISTOPHER ALEXANDER par Dr. Nikos A. Salingaros.
La bibliographie de l’ancêtre “malgré lui” du concept des design patterns en informatique.
… Plus beaucoup d’autres sites dont :

• Patterns and Software: Essential http://www.cmcrossroads.com/bradapp/docs/patterns-
intro.html
Concepts and Terminology
• Welcome to Core J2EE Patterns! http://java.sun.com/blueprints/corej2eepatterns/index.html
• Javarome.net http://javarome.free.fr
• EJB Patterns - Club d' entraide des http://knotty.developpez.com/j2ee/
développeurs francophones
• Hillside.net - Your Patterns Library http://hillside.net/patterns/
• DLFP: Comprendre les Design Patterns http://linuxfr.org/2002/04/17/7975.html

19
7 Bibliographie
Tout sur le code

Steve Mc Connell – Microsoft Press
Ce livre a pour but de faire l’inventaire des méthodes « pour concevoir du logiciel de qualité,
dans tous les langages ». Un must !
UML par la pratique

Pascal Roques – Eyrolles
Un cours simple et appliqué sur le langage UML avec des exemples d’implémentation en
Java et C#.
8 Glossaire des sigles
GOF : Gang Of Four. Groupe de 4 personnes ayant le plus largement contribué au

développement du concept des design pattern grâce à leur livre paru en 1995 : Design
Pattern ; Elements of reusable Object Oriented Software.
POO : Programmation Orientée Objet
OOPSLA : Object-Oriented Programming, Systems, Languages & Applications. Grand

messe récurrente sur le sujet de la programmation orienté objet. C’est lors d’une de ses
sessions en 1987 que le concept de design pattern a fait sa première apparition remarquée.
GRASP : General Responsability Assignement Software Patterns

20

2004 Les Design Patterns en OO

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2004 Les Design Patterns en OO

Transféré par

Droits d'auteur :

Formats disponibles

Les design patterns en programmation orientée objet

CNAM - Génie Logiciel

1 LES DESIGN PATTERNS ET LA CONCEPTION ORIENTEE OBJET ........................................ 4

2 LE CATALOGUE DE PATTERNS DU GANG OF FOUR.............................................................. 6

3 DESIGN PATTERN MODELE VUE CONTROLEUR : 3 PATTERN EN 1 ! ................................ 11

4 LE CATALOGUE DES PATTERNS GRASP............................................................................... 15

5 SYNTHESE & CONCLUSION...................................................................................................... 18

8 GLOSSAIRE DES SIGLES .......................................................................................................... 20

- Les design patterns en programmation orientée objet -

1.1 Les design patterns dans l’histoire

Les premiers concepts de la Programmation Orientée Objet [POO] apparaissent au cours

La POO se combine en phase de conception avec des langages de modélisation permettant

La combinaison de la POO et des Langages de modélisation conduit naturellement à franchir

- Les design patterns en programmation orientée objet -

Définition de Christopher Alexander :

“A pattern is a careful description of a perennial solution to a recurring problem within

Description extraite de Design Patterns: Elements of Reusable Object-Oriented :

Les design patterns constituent également un outil de communication entre programmeurs.

- Les design patterns en programmation orientée objet -

2.1 Design Patterns: Elements of Reusable Object-Oriented Software

Le Gang Of Four propose un regroupement des patterns en 3 catégories par objectif :

2. Les Structural Patterns : ces patterns proposent des modèles de composition

Le catalogue de design patterns est donc finalement présenté comme suit :

Creational Structural Behavioral

- Les design patterns en programmation orientée objet -

Un nom : Nommer un modèle de conception est la première étape. Elle va permettre un

• Un contexte : permettra de spécifier le champs d’application du pattern, la liste des

• Une implémentation : un exemple de code mettant en œuvre le pattern. Si cet

- Les design patterns en programmation orientée objet -

2.3.1 Le design pattern Singleton

L’astuce de ce pattern est d’instancier l’objet dont on veut éviter la

- Les design patterns en programmation orientée objet -

Il est intéressant de remarquer que cette solution fonctionne parfaitement en environnement

En effet, le scénario suivant pourrait se produire en multhread :

On trouve dans divers articles les solutions suivantes à ce problème :

On le voit, ces solutions sont très spécifiques à java.

2.3.3 Faut-il proposer une implémentation d’un design pattern ?

- Les design patterns en programmation orientée objet -

- Les design patterns en programmation orientée objet -

3.1 Le pattern Model-Vue-Controleur

Nom Model Vue Controleur, MVC, Model view controller (US)

Le modèle représente le comportement de l' application : traitements

La vue correspond à l' interface avec laquelle l'

- Les design patterns en programmation orientée objet -

Le contrôleur analyse la requête du client et appelle le modèle et la

Conséquences • Le faible couplage entre les composants du modèle implique

Le pattern MVC correspond un niveau de détail de conception faible. En augmentant ce

3.2 Le pattern Observateur et le modèle MVC

Un premier pattern à intervenir dans le modèle MVC est le pattern Observateur :

Nom observateur, observer (US)

Ceci est utile lorsque :

- Les design patterns en programmation orientée objet -

l’idée de ce pattern est de casser une dépendance réciproque entre

Conséquences Le maintient de la cohérence d’une application est facilité sans mettre

Le pattern observateur et le modèle MVC

- Les design patterns en programmation orientée objet -

Conséquences • Le client peut utiliser sans différence un composite, c'

Le pattern composite et le modèle MVC

- Les design patterns en programmation orientée objet -

4.1 Les GRASP

4.2 Quatre GRASP

4.2.1 Le pattern Expert

4.2.2 Le pattern Créateur