2007 08.cours - Design Patterns - Uml

INTRODUCTION AUX
DESIGN PATTERNS
Modèles de conception
réutilisables
D’après le catalogue d’Erich Gamma, Richard Helm, Ralph
Johnson et John Vlissides (1995).
Intro Design Patterns - 1

2007-2008
Pré requis
• Bases de la conception OO.
• Notation UML
– Diagrammes de classes
– Diagrammes d’objets
– Diagrammes de séquence
• Connaissance d’un langage OO (C++, Java, …).
• Expérience significative de Programmation OO.
• NB : dans ce support, les diagrammes de classes

présentés sont les originaux de Gamma et al., écrits en
OMT. La notation d’OMT est dans ce cas très proche
d’UML ; en cours/TD nous adapterons aisément en
UML.
2007-2008
Plan du Cours
1. Rappels de POO et d’UML.
2. Conception et réutilisation.
3. Design Patterns généraux (23, Erich
Gamma et al.).
Rq : On peut trouver par ailleurs des DP concernant des

domaines spécifiques comme la programmation
parallèle ou distribuée, le temps réel, les IHM, BDD
OO, réseaux, les graphes mathématiques, ...

2007-2008
I - Rappels de Programmation Orientée
Objet et d’UML

2007-2008
Rappels de termes de POO
• Classe : description d’un modèle d’objets semblables.
• Objet : instance d’une classe (création d’un objet =
instanciation)
• Classe abstraite : ne peut pas être instanciée
directement (dérivée en classes concrètes pour
instanciations).
• Attribut : élément d’information constitutif des objets
d’une classe.
• Méthode (fct° membre en C++) : élément de
comportement constitutif des objets d’une classe ;
réalise une opération.

2007-2008
Rappels de termes de POO
• Encapsulation : principe permettant de cacher les
éléments constitutifs des objets.
• Spécialisation/Généralisation (héritage) :
classification (passage d’une classe plus générale à une
classe plus spécifique) et inversement ; hiérarchisation
des classes.
• Association : relation entre classes ; décrit un ensemble
de liens entre objets.
• Conception [objet] : étape consistant à produire une
modélisation de l’application à réaliser.

2007-2008
Rappels de notation UML
• Unified Modeling Language.
• Synthèse de : OOSE/Use case
(Jacobson), OMT (Rumbaugh), Booch,
Harel (états-transitions), Shlaer et Mellor
(cycle de vie).
• Adopté par l’OMG en 1997.
• UML 2 …

2007-2008
UML
• Langage de modélisation standard.
• Très largement utilisé.
• Permet d’aller au delà des modèles simplement
structurels Entités/Relations.
• Permet de documenter les travaux.
• Très bon outil de communication des travaux (spéc.
fonctionnelles, dossier de conception, …).
• Les Design Patterns sont des composants logiques

décrits indépendamment d’un langage donné (dans 1
langage semi formel) => OMT, UML, …

2007-2008
Les 9 diagrammes d’UML
Réalisation du diagramme de
classes à l’aide du plugin
Omondo UML pour Eclipse.

2007-2008
Diagramme de classes
• Exprime la structure statique du
système.
• Classes + relations entre les classes.
• Interfaces, paquetages + leurs relations.

2007-2008
La classe
Nom de classe Nom de classe Nom de classe

Attributs
Méthodes
Exceptions
NomPaquetage1::NomPaquetage2::Nom de classe
<<stéréotype>>
Ex : <<signal>>, <<exception>>,
Nom de classe <<thread>> ; <<utilitaire>>

2007-2008
La classe
Niveau de visibilité Classe abstraite
(italique)
Bâtiment Nom de la classe

- adresse
# listePropriétaires Attributs
Étiquette de
commentaire + ajouterPropriétaire
+ enleverPropriétaire
Méthodes/opérations
- obtenirListe
Classe de tous
les types de . . .
constructions
habitées.
+ BâtimentNonTerminé Exceptions

2007-2008
Interface
• Décrit le comportement visible d’une
classe, composant, sous-sytème,
paquetage (et uniquement cela).
• = Méthodes « public » (+).
• Ni attribut ni association précisé.
• Rq : « interface » en Java ; en C++, pas
de mot-clé.

2007-2008
Interface
<<interface>> « Utilise »
Nom de classe
Nom interface
« Réalise »
ou
Utilisateur (
Nom de classe classe, …)
Cf. en Jave : « implements » pour réaliser et

« import » pour utiliser.

2007-2008
Association
Noms
Cardinalités

2007-2008
Agrégation, composition,
généralisation
• Agrégation
– Association non symétrique : 1 extrémité joue 1 rôle + important
(losange blanc).
• Composition
– Cas particulier d’agrégation avec un couplage + fort (losange
noir).
• Généralisation/Héritage
– Relation de classification entre un élément + général et un
élément + spécifique (triangle).

2007-2008
Exemple

2007-2008
Diagramme d’objets
• Diagramme d’objets ≡ diagramme
d’instances.
• Instance d’un diagramme de classes.
• Montre les objets et leurs liens.
• Présente une structure statique.
• Pour montrer un contexte, un exemple de
SDD complexe, etc.

2007-2008
Exemple

2007-2008
Diagramme de séquence
• Interactions entre objets.
• Représentation se concentrant sur la séquence
des opérations selon point de vue temporel.
• Modélise les aspects dynamiques des systèmes
Temps Réel et scénarios complexes avec peu
d’objets.
• Ne rend pas compte du contexte des objets de
manière explicite.
• Sert notamment à documenter les cas
d’utilisation (qui sont essentiels en analyse).
2007-2008
Notation

2007-2008
Exemple

2007-2008
2007-2008
II - Conception et de réutilisation

2007-2008
Qu’est-ce qu’un modèle (pattern)
de conception ?
• Domaine de l’Architecture (bâtiments et villes) :
Christopher Alexander (253 modèles de
conception, 1977)
– Chaque modèle décrit un problème qui se produit très
fréquemment dans notre environnement et
l’architecture de la solution à ce problème.
– C. Alexander déclare que l’on peut concevoir une
maison simplement par application successive de ses
modèles l’un après l’autre.
– Description : nom, quoi, pourquoi, quand, comment,
modèles en relation
• Hydraulique

2007-2008
Exemple de modèle d’Alexander
Nom : Transition d’entrée.
Quoi : Créer une transition du monde extérieur vers un
univers intérieur, plus privé.
Pourquoi : L’entrée dans un bâtiment influence la façon dont
on va se sentir à l’intérieur.
Quand : Systèmes d’accès et d’entrée pour les maisons, les
cliniques, les magasins, etc.
Comment : Créer un espace de transition entre la rue et la
porte d’entrée. Marquer le cheminement dans l’espace de
transition par un changement de lumière, un changement
de direction, etc.
Patterns en relation : vue Zen (#134), ...
tiré de «Introduction aux patterns» Jean Bézivin

2007-2008
Domaine Informatique :
Modèle de conception dans MVC de Smalltalk
• Classes Model/View/Controller (MVC) utilisé

pour construire des IHM en Smalltalk-80.
• Modèle = l’objet application.
• Vue = représentation visuelle de données.
• Contrôleur = définit le comportement de l’IHM
aux introductions de données.
• Séparation des vues et modèles + protocole de
communication par souscription et notification.
• Avant MVC : l’IHM était 1 simple agrégat
d’objets.
2007-2008
MVC
3 Vues
Contrôleur non
représenté ici
Modèle
• Rq : ce concept est généralisé dans le Design Pattern

Observateur.
2007-2008
Modèle de conception
• Documenter puis réutiliser un savoir-faire en
conception ayant fait ses preuves.
• Identifier, spécifier des abstractions d’un niveau
supérieur aux classes, instances.
• Moyen de documenter les logiciels.
• Aider à la construction de logiciels répondant à
des propriétés précises, de logiciels complexes.
• Abstraits, ils doivent être implémentés pour les
utiliser.
2007-2008
Réutilisation de code source :
Boite à outils/Librairie/Bibliothèque de classes
• Ensemble de classes (code source)
– Apparentées mais pour la plupart indépendantes,
– conçues pour offrir des fonctionnalités d’intérêt général,
– réutilisables,
– elles évitent au développeur de coder des fonctionnalités
d’usage très répandu.
• Ex : bibliothèque de gestion des flux d’E/S C++ iostream,
collections et structures de données (STL en C++), lib.
mathématiques …
• L’application utilisatrice importe la/les librairie(s).
• N’impose à l’application utilisatrice aucune contrainte de
conception.
• Généralement plus complexe à développer qu’une
application (quelles applis ? Quel besoins particuliers ?).
2007-2008
Réutilisation de conception :
Framework
• Un framework est un squelette d’application d’un
domaine particulier, composé d’un ensemble de
classes qui coopèrent.
• Impose une certaine architecture une application
(contraint et ainsi guide le développement).
• Toutes les applications développées sur la base
d’un framework donné ont par conséquent des
structures semblables (réutilisation de
conception vs réutilisation de code).
• L’adaptation de certaines classes du framework
à des besoins particuliers peut être effectuée
par le développeur à l’aide de l’héritage.
2007-2008
Techniques courantes pour la
réutilisation
1. Héritage
2. Composition d’objets
3. Types paramétrés dits « génériques » en Ada, Effeil ou
templates en C++
Conseils :
• Programmer une interface plutôt qu’une implémentation.
• Utiliser des classes abstraites en C++, interfaces en Java pour
définir des interfaces communes à un ensemble de classes.
• Déclarer les variables et paramètres comme des instances de la
classe abstraite plutôt que comme instances de classes
particulières.
– Conséquence : les classes clientes et les objets sont indépendants des
classes qui implémentent l’interface.

2007-2008
Comparaison entre héritage et
composition
• Héritage
– Défini de manière statique à la compilation.
– Permet de modifier facilement le code réutilisé.
– Pendant l’exécution, il n’est pas possible de modifier le code
hérité d’un parent.
– Une classe parente définit souvent une partie de la
représentation physique des futures sous-classes (=> rompt
l’encapsulation ; lie le code de la sous-classe à celui de la classe
parente)
– Si un caractère quelconque hérité ne convient pas à la sous-
classe, il faut re-écrire la classe parente.
– Peut mener à la multiplication inutile de sous-classes.
– Finalement : peu souple (l’idéal est de n’hériter que de classes
abstraites car peu ou pas de code).

2007-2008
Comparaison entre héritage et
composition
• Composition
– La composition d’objets est définie dynamiquement, à
l’exécution.
– Chaque objet composant peut être remplacé par un autre.
– Utilisation de la délégation (le récepteur délègue à son délégué
qui est un composant)
– Donc un peu plus lent à l’exécution mais plus souple.
– Multiplication des objets vs multiplication des classes (dév. +
léger)
• NB : Toujours se méfier de l’héritage : il est très souvent

préférable d’utiliser la composition d’objets.

2007-2008
III - Design Patterns généraux (Erich
Gamma et al.).

2007-2008
Comment présenter chaque
modèle de conception
• Un nom : utile pour l’identifier, communiquer,
documenter, faire de l’abstraction.
• Le problème : expose le sujet à traiter, la situation
et conditions pour qu’il puisse être appliqué.
• La solution : décrit les éléments qui constituent la
conception, leurs relations et coopérations.
• Les conséquences : implications de la mise en
œuvre de la solution (avantages / inconvénients) en
terme de mémoire, vitesse exécution, portabilité,
extensibilité, etc.

2007-2008
Classement des modèles :
3 groupes
Modèles Créateurs
• Expriment le principe du processus d’instanciation.
• Pour rendre les systèmes indépendants de la façon dont les objets
sont créés.
Modèles Structuraux
• Etudient la manière de composer classes et objets pour réaliser des
structures plus importantes.
• Utiles notamment pour permettre à des bibliothèques de classes
développées séparément de coopérer.
• Permettre des connections indépendantes des évolutions futures de
l’application : découpler l’interface des implémentations.
Modèles de comportement
• Traitent des comportements/algorithmes et de l’affectation des
responsabilités entre objets.
• Gestion des interactions dynamiques entre des classes et des
objets.
2007-2008
Classement des modèles

2007-2008
Modèles créateurs
• Fabrique abstraite (Abstract Factory) : interface pour
la création de familles d’objets sans spécifier de classe
concrète.
• Monteur (Builder) : séparation de la construction
d’objets complexes des parties qui les composent afin
qu’un même processus de construction puisse créer
différentes représentations.
• Fabrication (Factory Method) : définit une interface
pour la création d’objets en laissant le choix à des sous-
classes les choix des classes à instancier.
• Prototype : spécification des types d’objet à créer à
partir d’un objet prototype et crée les nouveaux objets en
copiant le prototype.
• Singleton : assure l’unicité de l’instance d’une classe.
2007-2008
Modèles structuraux
• Adaptateur (Adapter) : adapte/traduit l’interface d’une classe en
une autre interface qui correspond aux attentes du client.
• Pont (Bridge) : découple une abstraction de son implémentation
afin que les deux puissent être modifiés indépendamment l’un de
l’autre.
• Composite : structure pour la construction d’agrégations
récursives.
• Decorateur (Decorator) : attache dynamiquement des
responsabilités supplémentaires à un objet ; alternative à
l’héritage.
• Facade : fournit une interface unifiée à l’ensemble des interfaces
d’un sous-système ; simplifie l’utilisation du sous-système.
• Poids mouche (Flyweight) : utilise une technique de partage
quand un de nombreux objets de fine granularité sont à mettre
en œuvre.
• Procuration (Proxy) : fournit un mandataire pour contrôler
l’accès à un objet.
2007-2008
• Chaîne de responsabilités (Chain of Responsibility) :
délègue des requêtes à des responsables de services ;
évite couplage émetteur-récepteur.
• Commande : encapsule une requête par un objet ;
permet notamment la réversion des opérations (Undo).
• Interprète : étant donné un langage, définit une
représentation de sa grammaire.
• Itérateur : permet le parcours séquentiel des collections.
• Médiateur : encapsule les modalités d’interaction d’un
ensemble d’objets ; favorise le couplage faible ; schéma
en étoile.
• Mémento : capture et restauration de l’état d’un objet.
2007-2008
• Observateur : mise à jour automatique des objets
dépendants d’un objet.
• Etat : permettre à un objet de modifier son
comportement lorsque son état interne change, comme
s’il changeait de classe.
• Stratégie : abstraction pour sélectionner un algorithme
parmi plusieurs disponibles.
• Patron de méthode (Template method) : dans une
opération, définit le squelette d’un algorithme dont
certaines étapes sont fournies par des sous-classes.
• Visiteur : représente une opération à effectuer sur les
éléments d’une structure d’objet ; permet de définir une
nouvelle opération sans modifier les classes des
éléments sur lesquels il opère.
2007-2008
Relations entre les modèles de conception

2007-2008
1 - DP Singleton (créateur)
• Intention
– Garantit qu’une classe n’a qu’une seule instance et fournit un
point d’accès de type global à cette classe
– Tous les utilisateurs de la classe utilisent la même instance.
• Principe
– Définir une opération permettant au client d’obtenir l’unique
instance de la classe Singleton

2007-2008
DP Singleton
• Très simple, le DP singleton est largement
utilisé pour accéder à des ressources système
telles que le presse-papier (clipboard).
• Evite de polluer l’espace de nom global par
des variables statiques.
• La mise en œuvre de ce pattern est à faire
avec prudence si plusieurs threads (Cf. cours
prog. parallèle) peuvent accéder à l’instance
unique.

2007-2008
DP Singleton
• En C++ : méthode de classe (fonction membre
static).
• On peut adapter facilement le modèle pour
permettre la création d’un nombre voulu
d’instances.
• Attention en C++ : une méthode static ne peut
pas être virtuelle => pas de liaison dynamique
possible en cas d’héritage.
• Classiquement, on masque le constructeur (le
client ne peut alors qu’appeler la méthode
statique).

2007-2008
Exercice
• Proposez une solution d’implémentation
en C++ pour une classe Clipboard
permettant de stocker un texte et de
l’obtenir (lire).

2007-2008
2 - DP Observateur
(comportement)
• Intention
– Définir une interdépendance de type 1 à plusieurs, telle
que lorsque un objet change d’état, tous les objets qui
en dépendent en sont notifiés et automatiquement mis à
jour.

2007-2008
Diagramme de classes
Le sujet est observé par 0 à n observateurs.

2007-2008
Diagramme de séquence
• Exemple : 1 sujet + 2 observateurs
• Modèle ‘PUSH’ : le sujet envoie aux observateurs une info détaillée sur les modifs
(suppose par conséquent que sujet sait ce qui les intéresse ou qu’il envoie toutes
les modifs, via par ex. un objet).
• Modèle ‘PULL’ : le sujet notifie simplement puis les observateurs réclament les
détails (GetState()). (plus souple mais peut être moins efficace).

2007-2008
Exercice
• Le système de surveillance
– Une simulation avec un thermomètre relié à
des alarmes de plusieurs sortes et dont les
températures de déclenchement sont
paramétrables.
– Modèle de conception + Code source C++.

2007-2008
3 - DP Composite (structurel)
• Intention
– Composer des objets en des structures
arborescentes pour représenter des hiérarchies
composant / composé et permettre au client de traiter
de la même manière les éléments terminaux et
composites.
• Principe
– Une classe abstraite représente à la fois les éléments
primitifs et les éléments composites (containers).

2007-2008
DP Composite

2007-2008
DP Composite

2007-2008
4 - DP Pont (structurel ; syn. Bridge,
Poignée/Corps, Handle-Body)
• Intention :
– Découpler une abstraction de son implémentation afin
que chacun puisse être modifié indépendamment de
l’autre.
• Quand une abstraction peut avoir différentes
implémentations, une solution pour les lier =
l’héritage.
– 1 classe de base abstraite qui définit l’interface
commune ; les héritières concrètes l’implémente
– Manque de souplesse : liaison immuable entre la
classe de base et chaque classe dérivée.

2007-2008
DP Pont
Deux hiérarchies de classes séparées :
1. Hiérarchie pour les interfaces/classes abstraites
2. Hiérarchie pour les implémentations
Exemple :
ApplicationWindow

2007-2008
DP Pont
• Favorise le développement en couches

• Dissimule les détails d’implémentation au client (*) tant que
partage d’objets « implémenteurs », éventuellement les
mécanismes de comptage de références)

2007-2008
DP Pont
• Choix de la classe d’implémentation :
– Si toutes les classes d’implémenteur sont connues par
l’abstraction, on peut passer un paramètre au
constructeur de l’abstraction. Ex : Collection abstraite :
en fct° de la taille a priori, le constructeur crée une liste
chainée ou une table de hachage (grandes tailles).
Autre possibilité : une implémentation initiale qui
change au-delà d’une taille atteinte.
– Autres possibilités : déléguer à un autre objet le choix
de l’implémentation (délégation à une Fabrique
Abstraite par ex.), lire un/des paramètres
d’environnement.
2007-2008
5 - DP Commande (comportement)
• Intention
– encapsuler une requête par un objet (permet
notamment la réversion des opérations).

2007-2008
DP Commande
• Ici le récepteur est l’application qui gère le document (le document

n’existe pas avant d’exécuter la commande).

2007-2008
DP Commande
• Macro commandes : séquence de commandes simples ou

macros.
• Undo : l’opération Execute() peut stocker un état dans l’objet
commande pour le rétablir ; l’interface de Command doit
posséder une opération supplémentaire : Undo().

2007-2008
Exercice
• On suppose que l’on dispose des commandes
Filtre1, Filtre2, .. FiltreN implémentant le D.P.
Command dans une application de traitement
d’images.
• On veut écrire une classe de macro commandes
de traitements d’images.
• Donnez le modèle de conception faisant
intervenir les N filtres et la macro commande
puis une implémentation minimale de cette
dernière en C++.

2007-2008
6 - DP Procuration
(structurel, Proxy, subrogé)
• Intention : fournir un mandataire/remplaçant
pour contrôler l’accès à un objet.
• Motivation : différer ce qui est coûteux dans la
création et l’initialisation d’un objet au moment
du son utilisation effective.
• Ex. : doc traitement de texte avec images
volumineuses ; simple encombrement de
l’image ou bien affichage de l’image.

2007-2008
DP Procuration
Rq : pour une image de petite taille,

il n’est pas forcément nécessaire
Intro Design Patterns - d’utiliser un proxy (heuristique). 64
2007-2008
DP Procuration
• Indications d’utilisation :
– procuration virtuelle (Cf. images),
– procuration à distance (espace d’@ ≠),
– procuration de protection,
– pointeurs intelligents (Smart Pointers).

2007-2008
Exercice
• Pointeur intelligent : référence un objet
exactement comme un pointeur, mais il
n’est pas nécessaire de faire
manuellement les destructions.
• Déclarer et implémenter l’interface
minimale d’une classe C++ SmartPtrInt de
pointeurs intelligents sur des entiers (int) ;
on généraliserait sans difficulté en faisant
un patron (template) de cette classe.

2007-2008
7 - DP Fabrique Abstraite
(créateur, Kit)
• Intention : fournir une interface pour la création
de familles d’objets sans spécifier de classe
concrète.
• Ex : boite à outils pour IHM avec plusieurs look-
and-feels.
• Code client indépendant du look-and-feel.

2007-2008
DP Fabrique Abstraite
• La classe abstraite WidgetFactory définit une
interface (ici non exhaustive) pour créer chaque
catégorie de widgets (= objets graphiques).

2007-2008

2007-2008
• Souvent implémentation des fabriques
concrètes sous forme de DP Singletons.
• Pour fabriquer de nombreuses sortes d’objets,
on peut implémenter la fabrique à l’aide du DP
Prototype ; la fabrique crée un nouveau produit
par clonage du prototype du produit. (la classe
abstraite Prototype contient une méthode
clone() qui retourne la copie de l’objet sur lequel
elle est invoquée : le prototype se clone lui
même).
• Les familles d’objets doivent donc dans ce cas
être « clonable » (Cf. cours de Java)
2007-2008
8 - DP Etat (Comportement, alias
« objets d’état »)
• Intention : permet à un objet de modifier son
comportement lorsque son état interne change,
comme s’il changeait de classe.
• Indication d’utilisation :
– Le comportement d’un objet dépend de son état et
l’état change dynamiquement.
– Les opérations de la classe comportent de grands
pans de déclarations conditionnelles fonctions de
l’état de l’objet (if / else à éviter au maximum !) que
l’on retrouve de plus souvent dans les différentes
opérations.

2007-2008
DP Etat
* Context : définit l’interface intéressant les clients et gère un objet
état d’une des classes concrètes.
* State : définit une interface encapsulant le comportement associé

à un état particulier du contexte.
* ConcreteStateX : Chaque sous-classe implémente le comportement

d’un état des objets de classe Context

2007-2008
DP Etat – Application directe
• Exercice : représenter un automate à états fini.
‘e’ ‘d’ ‘f’

s0 s1 s2
‘g’

2007-2008
current,
start 2
Automaton State
Automaton() automaton void next(char c)

~Automaton()
void setStartState(State * s)
void start()
void get_input(char c)
void setCurrentState(State * s)
S0 S1 S2
void next(char c) void next(char c) void next(char c)

2007-2008
• Les états initial et final seront représentés par un objet NULL.
Les transitions se font quand le caractère est reçu par
l’automate (ex : l’automate dans l’état s0 passe à l’état s1 s’il
reçoit le caractère ‘e’ mais il ne change pas d’état pour tout
autre caractère).
• Quant l’automate est créé, il est sans état, les états initial et
courant sont NULL ; setStartState() permet de renseigner
l’état initial (s0) de l’automate ; start() positionne l’automate
sur cet état ; get_input() permet à l’automate de recevoir un
caractère (et donc parfois de changer d’état) ;
setCurrentState() permet de changer l’état courant de
l’automate. Dans les classes d’états, la méthode next()
permet de changer d’état courant quand le caractère reçu est
un caractère qui permet une transition.

2007-2008
9 - DP Stratégie (Comportement)
(alias : Politique, Strategy, Policy)
• Intention : définit une famille d’algorithmes, encapsule
chacun d’eux et les rend interchangeables. Cela permet
aux algorithmes d’évoluer (être modifiés)
indépendamment des clients utilisateurs.
– Un algorithme encapsulé est dit « stratégie ».
• Indication :
– plusieurs classes apparentées ne diffèrent que par leur
comportement,
– On a besoin de plusieurs variantes d’un algorithme (différentes
optimisations selon vitesse / occup. Mémoire)
– Un algo utilise des données que le client n’a pas à connaître
(évite de révéler les SDD spécifiques, internes des algos)
– Une classe définit de nombreux comportement (if / else à éviter
!)

2007-2008
Stratégie
* Strategy : déclare une interface commune à tous les algorithmes
définis. Contexte utilise cette interface pour appeler l’algorithme défini
par un objet ConcreteStrategyX.
* ConcreteStrategy : implémente un algo particulier.
* Contexte : fait référence à un objet stratégie concrète.

2007-2008
class Strategy {
Stratégie
public: virtual void runAlgorithm() = 0;
};
class Context {
private:
Strategy * strategy;
public:
Context() { strategy = new ConcreteStrategyA(); }
void changeStrategy(const Strategy & newS) {if (strategy) delete strategy ; strategy = new Strategy(newS); }
void getResult() { strategy.runAlgorithm(); }
};
class ConcreteStrategyA : Strategy {

public: void runAlgorithm() { // implém algo A }
};
class ConcreteStrategyB : Strategy {

public: void runAlgorithm() { // implém algo B }
};
int main() {
Context * context = new Context();
context->getResult();
concreteStrategyB sB;
context->changeStrategy(sB);
context->getResult();
}

2007-2008
Pont vs Stratégie
• On peut confondre à première vue les 2
patterns.
• Ils ont même structure, cependant ils permettent
de résoudre des problèmes différents.
• La Stratégie traite de l’encapsulation
d’algorithmes alors que le Pont découple
l’abstraction de l’implémentation ce qui permet
pour une même abstraction d’avoir plusieurs
implémentations.

2007-2008
Autres Designs patterns :
le DP « Marqueur »
• Intention : signaler qu’une classe possède
une propriété particulière.
• Principe : le marqueur est une interface
qui ne possède ni attribut ni méthode. Son
seul intérêt est de signaler qu’une classe
possède une caractéristique particulière.
• Dans la plateforme Java (Cf. cours Java),
il est largement utilisé (ex : interface
Serializable, Clonable, …).
2007-2008
Autres Designs patterns :
le DP « Immuable »
• Intention : évite les effets de bord lors des
changements d’états d’un objet et améliore les
performances en cas d’accès concurrents
• Principe :
– créer un objet qui ne peut pas changer d’état ; ce
dernier est fixé une fois pour toutes lors de
l’instanciation de l’objet et ne peut plus être modifié.
– Si l’on souhaite effectuer une modification sur l’objet,
il faut en faire une copie modifiée.
• En Java, utilisé par ex. pour la classe String.
2007-2008
Références
• L’Indispensable « Design Patterns – Catalogue de
modèles de conception réutilisables », Erich Gamma et
al., Editions Addison Wesley - Vuibert. (version originale
en anglais) qui propose de nombreux articles
« historiques ».
• Google !

2007-2008

2007 08.cours - Design Patterns - Uml

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

2007 08.cours - Design Patterns - Uml

Transféré par

Droits d'auteur :

Formats disponibles

INTRODUCTION AUX

Intro Design Patterns - 1

• NB : dans ce support, les diagrammes de classes

Rq : On peut trouver par ailleurs des DP concernant des

Intro Design Patterns - 3

Intro Design Patterns - 4

Intro Design Patterns - 5

Intro Design Patterns - 6

Intro Design Patterns - 7

• Les Design Patterns sont des composants logiques

Intro Design Patterns - 8

Intro Design Patterns - 9

Intro Design Patterns - 10

Nom de classe Nom de classe Nom de classe

Intro Design Patterns - 11

Bâtiment Nom de la classe

Intro Design Patterns - 12

Intro Design Patterns - 13

Cf. en Jave : « implements » pour réaliser et

Intro Design Patterns - 14

Intro Design Patterns - 15

Intro Design Patterns - 16

Intro Design Patterns - 17

Intro Design Patterns - 18

Intro Design Patterns - 19

Intro Design Patterns - 21

Intro Design Patterns - 22

Intro Design Patterns - 24

Intro Design Patterns - 25

tiré de «Introduction aux patterns» Jean Bézivin

Intro Design Patterns - 26

• Classes Model/View/Controller (MVC) utilisé

• Rq : ce concept est généralisé dans le Design Pattern

Intro Design Patterns - 32

Intro Design Patterns - 33

• NB : Toujours se méfier de l’héritage : il est très souvent

Intro Design Patterns - 34

Intro Design Patterns - 35

Intro Design Patterns - 36

Intro Design Patterns - 38

Intro Design Patterns - 43

Intro Design Patterns - 44

Intro Design Patterns - 45

Intro Design Patterns - 46

Intro Design Patterns - 47

Intro Design Patterns - 48

Intro Design Patterns - 49

Intro Design Patterns - 50

Intro Design Patterns - 51

Intro Design Patterns - 52

Intro Design Patterns - 53

Intro Design Patterns - 54

Intro Design Patterns - 55

Intro Design Patterns - 56

• Favorise le développement en couches

Intro Design Patterns - 57

Intro Design Patterns - 59

• Ici le récepteur est l’application qui gère le document (le document

Intro Design Patterns - 60

• Macro commandes : séquence de commandes simples ou

Intro Design Patterns - 61

Intro Design Patterns - 62

Intro Design Patterns - 63