UML All in One

20/10/2020
DESIGN PATTERN
Les patterns GoF
La conception Orientée objet

2
 Un art difficile...
 Une conception réutilisable, extensible, adaptable,
performante  extrêmement difficile.
 Quelle est la différence entre un novice et un
concepteur expérimenté
 le novice hésite beaucoup entre différentes variantes
 l’expert trouve tout de suite la bonne solution.
 Quel est le secret ?

 l’EXPERIENCE !
1
20/10/2020
La conception Orientée objet

3
 L’expérience c’est
 ne pas réinventer la roue,
 réutiliser systématiquement des solutions qui ont fait leurs
preuves,
 pour une conception modulaire, élégante, adaptable
 répétition de certains profils de classes ou
collaboration d’objets
 lesdesign patterns
 = modèles de conception
 = patrons de conception
Définition
4
 Un pattern est une bonne pratique face à un problème courant.
 Un pattern est une capitalisation du savoir-faire et de l’expérience
pour résoudre des problèmes récurrents intervenants dans les
différents niveaux du processus:
 analyse (analysis pattern),
 architecture (architectural pattern)
 conception (design pattern)
 programmation (idiomes ou idiomatiques en français)
 C’est un moyen de partager la connaissance de la résolution

d’un type de problème sous une forme « conceptuelle », mais
ce n’est pas une solution implémentée.
 Aide à la construction de logiciels répondant à des
propriétés précises, de logiciels complexes et hétérogènes
 Traductions : patrons de conception, schémas de conception,
motifs de conception
2
20/10/2020
Définition
5
 Un design pattern décrit une structure commune et

répétitive de composants en interaction (la solution)
qui résout un problème récurrent de conception dans
un contexte particulier.
 Qu’est-ce qu’un bon patron de conception ?
 il résout un problème
 c’est un concept éprouvé
 la solution n’est pas évidente
 il décrit une collaboration entre objets
Objectifs
6
 Modularité
 Facilité de gestion (technologie objet)
 Cohésion
 Degré avec lequel les tâches réalisées par un seul module
sont fonctionnellement reliées
 Une forte cohésion est une bonne qualité
 Couplage
 Degré d’interaction entre les modules dans le système
 Un couplage faible est une bonne qualité
 Réutilisabilité
 Bibliothèques, frameworks (cadres)
3
20/10/2020
Exemple « mauvaise » cohésion

7
Exemple: « bonne » cohésion

8
4
20/10/2020
Exemple : couplage
9
10
5
20/10/2020
Ouvrage de référence
11
Les design Patterns GoF

12
 Très célèbres
 conçus par 4 informaticiens : Erich Gamma, Richard
Helm, Ralph Johnson et John Vlissides, surnommés le
”Gang of Four” (GoF)
 Ils proposent des solutions élégantes, pour résoudre
différents problèmes récurrents rencontrés par les
architectes logiciels.
 Le catalogue GoF patterns (23 patterns)
6
20/10/2020
Catégories de Design Patterns

13
 Création
 Description de la manière dont un objet ou un ensemble
d’objets peuvent être créés, initialisés, et configurés
 Singleton
 Fabrication (Factory Method)

 Fabrique abstraite (Abstract Factory)
 Monteur (builder)
 Prototype (Prototype )

14
 Structure
 Description de la manière dont doivent être connectés des objets
de l’application afin de rendre ces connections indépendantes
des évolutions futures de l’application
 Découplage de l’interface et de l’implémentation de classes et
d’objets
 Adaptateur (Adapter) ,
 Pont (Bridge) ,
 Objet composite (Composite),
 Décorateur (Decorator) ,
 Façade (Facade) ,
 Poids-mouche ou poids-plume (Flyweight) ,
 Proxy (Proxy)
7
20/10/2020

15
 Comportement
 Description de comportements d’interaction entre objets
 Gestion des interactions dynamiques entre des classes et des
objets
 Chaîne de responsabilité (Chain of responsibility),
 Commande (Command) ,
 Interpréteur (Interpreter)
 Itérateur (Iterator),
 Médiateur (Mediator)
 Memento (Memento)
 Observateur (Observer)
 État (State)
 Stratégie (Strategy)
 Patron de méthode (Template Method)
 Visiteur (Visitor)
8
27/10/2020
1 Design patterns de création

•Abstraction du processus de création
•Encapsulation de la logique de création
•On ne sait pas à l'avance ce qui sera créé ou comment

cela sera créé
Patron de conception
Singleton : présentation
2
 Intention
 S’assurer qu’une classe a une seule instance, et fournir un point
d’accès global à celle-ci.
 Exemple
 Un seul window manager, un seul point d’accès à une base de
données, un seul pilote de périphérique (instancier plus qu’une fois
surcharge inutile, comportement incohérent)
 Comment créer une classe utilisée plusieurs fois dans une
application mais instanciée une seule fois?
 Solution
 Le Singleton va permettre de récupérer l'objet unique, sans se soucier de
vérifier si il existe déjà ou pas
 rendre le constructeur de la classe privée.
 méthode statique qui retournera un objet correspondant au type de la
classe
1
27/10/2020
Singleton: Diagramme
3
 Construire un pseudo constructeur

 Déclarer une méthode statique qui retourne un objet de type de la classe
 On peut contrôler la valeur retournée
Singleton : implémentation
4
public class Singleton {
/** Création de l'instance au niveau de la variable statique. */
private static Singleton INSTANCE = null;
/**La présence d'un constructeur privé supprime
* le constructeur public par défaut. */
private Singleton() {}
/**Retourne l'instance du singleton. */
public static Singleton getInstance() {
If(INSTANCE ==null) {
INSTANCE =new Singleton()
}
return INSTANCE;
}
/** A partir d'ici, toutes les méthodes de l'instance (non statique)
*/
}
2
27/10/2020
Pattern Factory: présentation

5
 Les langages oo fournissent des mécanismes d’instanciation et d’initialisation(new,

newobj,..) : utiliser sans prévoir les conséquences  inflexibilités des systèmes due
au couplage fort entre créateur et classe à créer
 Solution : modèles créateurs décrivant les mécanismes de création des objets qui
favorisent la réutilisation
 il y a un certain nombre de variations du modèle de fabrique de classe
 la plupart des variantes utilisent le même jeu d’acteurs primaires, un Client, une
Fabrique et un Produit (Client, Factory, Product).
 Le client utilise la fabrique pour créer une instance du produit.
 La fabrique rend abstraite, pour le client, la création et l’initialisation du produit.

 si l’implémentation du produit change dans le temps, le client quant à lui reste
inchangé.
Factory Method : présentation

6
 Intention
 Définit une classe pour la création d’un objet, mais en laissant à
des sous-classes le choix des classes à instancier
 Permet la délégation d’instanciation
 Exemple
 Instancier des classes, en connaissant uniquement les classes
abstraites.
 Framework pour des applications qui présentent des
documents multiples à l’utilisateur
3
27/10/2020
Factory Method : diagramme

7
Champs d’application
 une classe ne peut pas anticiper l’objet qu’elle doit construire (utiliser)
 une classe délègue la responsabilité de la création à ses sousclasses, tout en
concentrant l'interface dans une classe unique
Factory Method: structure


8
Structure :
 Objet à créer :
 Une interface (ou classe abstraite) Product
 définit l’interface des objets créés par la fabrication
 Une ou plusieurs classes concrètes : ConcreteProduct
 implémente l’interface Product
 Createur
 Une classe abstraite, Creator :
 déclare la fabrication; celle-ci renvoie un objet de type Product. Le
Creator peut également définir une implémentation par défaut de la
fabrication, qui renvoie un objet ConcreteProduct par défaut. Il peut
appeler la fabrication pour créer un objet Product.
 public abstract Product FactoryMethod();
 Une ou plusieurs classes concrètes ConcreteCreator, qui retournent des
ConcreteProduct
4
27/10/2020
Factory Method: conséquences

9
 Conséquence :
 La fabrication dispense d’avoir à incorporer à son code
des classes spécifiques de l’application. Le code ne
concerne que l’interface Product, il peut donc fonctionner
avec toute classe ConcreteProduct définie par
l’utilisateur
 La création d’objets à l’intérieur d’une classe avec la
méthode fabrication est toujours plus flexible que la
création d’un objet directement
Exemple
10
5
27/10/2020
Factory Method :implementation

11
 Implémentation (2 possibilités)
 La classe Creator est une classe abstraite et ne fournit pas
d’implémentation
 La classe Creator est une classe concrète qui fournit une
implémentation par défaut pour la fabrication
 Fabrication paramétrée
 Utilisation de paramètres pour déterminer la variété d’objet
 Exemple : fabrique de documents, choix d’objet en fonction
de dimensions, etc.
Abstract Factory : présentation

12
 Intention
 Le pattern abstract factory fournit une interface pour la
création de familles d'objets apparentés ou indépendants
sans devoir spécifier leurs classes concrètes.
 Exemple:
 une boite à outils qui supporte de multiples apparences :
motif et présentation Manager : pour qu’une application soit
portable indépendamment de l’apparence utilisée les widgets
ne doivent pas être codés en dur
6
27/10/2020
13
Abstract Factory: utilisation

14
 Champs d’application
 Indépendance de comment les objets/produits sont créés,
composés et représentés
 Configuration d’un système par une instance d’une multitude
de familles de produits
 Conception d’une famille d’objets pour être utilisés ensemble
et contrôle de cette contrainte
 Bibliothèque fournie avec seulement leurs interfaces, pas leurs
implémentations
(bibliothèque graphique, look-and-feel)
7
27/10/2020
Abstract Factory : diagramme

15
Abstract Factory : structure

16
 Structure
 La fabrique
 AbstractFactory déclare l’interface pour les opérations qui créent des
objets abstraits
 ConcreteFactory implémente les opérations qui créent les objets concrets
 Les objets (plusieurs types)
 AbstractProduct déclare une interface pour un type d’objet
 ConcreteProduct définit un objet qui doit être créé par la fabrique
concrète correspondante et implémente l’interface AbstractProduct
 L’utilisateur
 Client utilise seulement les interfaces déclarée par AbstractFactory et par
les classes AbstractProduct
8
27/10/2020
Abstract Factory: collaboration

17
 Collaborations
 Normalement, une seule instance de fabrique concrète
est créée à l’exécution. Cette fabrique crée les objets
avec une implémentation spécifique. Pour créer
différents sortes d’objets, les clients doivent utiliser
différentes fabriques concrètes.
 La fabrique abstraite défère la création des objets à ses
sous-classes concrètes
Abstract Factory :conséquences

18
 Conséquences
 Isolationdes classes concrètes (seules les classes
abstraites sont connues)
 Échange facile des familles de produit
 Encouragement de la cohérence entre les produits
 Prise en compte difficile de nouvelles formes de produit

car Abstract Factory détermine les produits qui peuvent
être crées
9
27/10/2020
Abstract Factory : implémentation

19
 Implémentation
 Les fabriques sont souvent des singletons
 Ce sont les sous-classes concrètes qui font la création, en
utilisant le plus souvent une Factory Method
20
10
27/10/2020
21
22
11
27/10/2020
23
24
12
27/10/2020
25
26
13
27/10/2020
27
28
14
27/10/2020
29
Builder : présentation
30
 Intention
 Séparer la construction d’un objet complexe de sa représentation, de
sorte que le même processus de construction adapte la représentation
selon les objets
 Exemple
 Dans un carnet d’adresse, traiter de la même façon les personnes et les
groupes
 Manipuler ensemble des objets « proches » (générateur d’interface le cas
des différentes fenêtres d'une IHM. Elles comportent des éléments
similaires (titre, boutons), mais chacune avec des particularités (libellés,
comportements)
15
27/10/2020
Builder: diagramme
31
Builder: structure
32
 Structure
 ObjetComplexe : est la classe d'objet complexe à instancier.
 Monteur : définit l'interface des méthodes permettant de créer les différentes parties
de l'objet complexe.
 ConcreteMonteurA et ConcreteMonteurB : implémentent les méthodes permettant de
créer les différentes parties. Les classes conservent l'objet durant sa construction et
fournissent un moyen de récupérer le résultat de la construction.
 Directeur : construit un objet en appelant les méthodes d'un Monteur.
 La partie cliente instancie un Monteur. Elle le fournit au Directeur. Elle appelle la
méthode de contruction du Directeur.
 Conséquences
 La représentations internes d’un objet peut varier.
 La modularité : les builders sont indépendants
16
27/10/2020
Modèle
33
Exemple
34
17
27/10/2020
Application
35
 Le Client a besoin de convertir un doc du RTF au format

ASCII
 Il appelle une methode createASCIIText qui a commme
paramètre le document à convertir
 Cette méthode appelle la classe (concrete builder)
ASCIIConverter, sous classe de (Builder)TextConverter,
 La classe (Director) RTFReader, parcourt le document et
appelle la méthode du builder selon le token rencontré.
 La classe (product) ASCIIText, est construite étape par
étape, en ajoutant les caractères convertis
Implémentation Java
36
//Abstract Builder
class abstract class TextConverter{
abstract void convertCharacter(char c);
abstract void convertParagraph();
}
// Product
class ASCIIText{
public void append(char c){ //Implement the code
here }
}
18
27/10/2020
//Concrete Builder
class ASCIIConverter extends TextConverter{
ASCIIText asciiTextObj;//resulting product
/*converts a character to target representation and appends to

the resulting*/
object void convertCharacter(char c){
char asciiChar = new Character(c).charValue();
//gets the ascii character
asciiTextObj.append(asciiChar);
}
void convertParagraph(){}
ASCIIText getResult(){
return asciiTextObj;
}
}
37
//This class abstracts the document object

class Document{
static int value;
char token;
public char getNextToken(){
//Get the next token
return token;
}
}
38
19
27/10/2020
//Director
class RTFReader{
private static final char EOF='0'; //Delimitor for End of File
final char CHAR='c';
final char PARA='p';
char t;
TextConverter builder;
RTFReader(TextConverter obj){
builder=obj;
}
void parseRTF(Document doc){
while ((t=doc.getNextToken())!= EOF){
switch (t){
case CHAR: builder.convertCharacter(t);
case PARA: builder.convertParagraph();
}
}
}
}
39
//Client
public class Client{
void createASCIIText(Document doc){
ASCIIConverter asciiBuilder = new ASCIIConverter();
RTFReader rtfReader = new RTFReader(asciiBuilder);
rtfReader.parseRTF(doc);
ASCIIText asciiText = asciiBuilder.getResult();
}
public static void main(String args[]){
Client client=new Client();
Document doc=new Document();
client.createASCIIText(doc);
system.out.println("This is an example of Builder Pattern");
}
}
40
20
27/10/2020
Exemple d’implémentationn de la classe

41
produit
/* Produit */ class Pizza { private String pate = "";

private String sauce = ""; private String garniture = "";
public void setPate(String pate) { this.pate = pate; }
public void setSauce(String sauce) { this.sauce = sauce; }
public void setGarniture(String garniture) { this.garniture
= garniture; } }

42
Monteur
/* Monteur */ abstract class MonteurPizza

{ protected Pizza pizza;
public Pizza getPizza() { return pizza; }
public void creerNouvellePizza()
{ pizza = new Pizza(); }
public abstract void monterPate();
public abstract void monterSauce();
public abstract void monterGarniture(); }
21
27/10/2020

43
MonteurConcret
/* MonteurConcret */ class MonteurPizzaHawaii

extends MonteurPizza
{ public void monterPate() { pizza.setPate("croisée");
}
public void monterSauce() { pizza.setSauce("douce"); }
public void monterGarniture() {
pizza.setGarniture("jambon+ananas"); } }
Exemple d’implémentation de la classe

44
Directeur
/* Directeur */ class Serveur {

private MonteurPizza monteurPizza;
public void setMonteurPizza(MonteurPizza mp)
{ monteurPizza = mp; }
public Pizza getPizza() { return monteurPizza.getPizza();
}
public void construirePizza()
{ monteurPizza.creerNouvellePizza();
monteurPizza.monterPate();
monteurPizza.monterSauce();
monteurPizza.monterGarniture(); } }
22
27/10/2020
Exemple d’implémentation de la classe

45
Client
/* Un client commandant une pizza. */ class ExempleMonteur {

public static void main(String[] args) {
Serveur serveur = new Serveur();
MonteurPizza monteurPizzaHawaii = new MonteurPizzaHawaii();
MonteurPizza monteurPizzaPiquante = new MonteurPizzaPiquante();
serveur.setMonteurPizza(monteurPizzaHawaii);
serveur.construirePizza();
Pizza pizzas = serveur.getPizza(); } }
Prototype
46
 Intention
 Dupliquer (cloner) un objet trop coûteux à créer
 Créer des objets différents uniquement par le comportement. Le
prototype sert de modèle.
 Exemple
 Le système doit créer de nouvelles instances, mais il ignore de quelle classe. Il
dispose cependant d'instances de la classe désirée.
 Cela peut être le cas d'un logiciel de DAO comportant un copier-coller.
L'utilisateur sélectionne un élément graphique (cercle, rectangle, ...), mais la
classe traitant la demande de copier-coller ne connaît pas la classe exacte
de l'élément à copier.
 La solution est de disposer d'une duplication des instances (élément à copier :
cercle, rectangle). La duplication peut être également intéressante pour les
performances (la duplication est plus rapide que l'instanciation).
23
27/10/2020
Prototype: diagramme
47
Prototype
48
 Structure
 Prototype : définit l'interface de duplication de soi-même.
 ConcretePrototypeA et ConcretePrototypeB : sont des sous-
classes concrètes de Prototype. Elles implémentent l'inteface
de duplication.
 La partie cliente appelle la méthode clone() de la classe
Prototype. Cette méthode retourne un double de l'instance.
 Conséquences
 Création d’instances « différentes » sans créer de classe
24
17/11/2020
Design patterns de structure

Découplage de l’interface et de l’implémentation
de classes et d’objets
Adaptateur
 Le pattern Adaptateur permet de transformer une
interface d'une classe en une autre conforme à celle
attendue par le client. L'adaptateur permet à des
classes de collaborer alors qu'elles n'auraient pas
pu le faire du fait d'interfaces incompatibles.
1
17/11/2020
Patron de structure
Adaptateur
 Contexte
 Un service est défini par une interface; les clients appellent le
service via cette interface; les servants implantent l’interface
 Problème
 Réutiliser un servant qui implante une interface non-conforme
à l’interface attendue par les clients
 Solution
 Introduire un composant (adapter ou wrapper) représentant
une couche de transformation entre les clients et le servant
 L’adapter intercepte les requêtes et réponses du servant et
les adapte de façon à les rendre conformes avec l’interface
attendue
réutilisation
 Deux techniques :
 L'héritage: réutilisation boîte blanche. On parle de
boîte blanche, car le contenu des classes parentes est
visible aux sous classes
 La composition: réutilisation boîte noire . On parle de
boîte noire, car la nouvelle classes n'a pas accès à la
représentation interne de l'objet réutilisé.
2
17/11/2020
L'héritage et ses principes
 Il est défini de façon statique à la compilation

 L'utilisation dans la sous classe est immédiate
 La sous classe peut surcharger quelques opérations
tout en gardant l'accès à la version de la classe
Parent.
 La sous classe dépend des changements de la
classe Parent. L'héritage rompt l'encapsulation.
 Impossibilité de modifier à l'exécution le code hérité
des parents
Réutilisation par héritage

 •Réutilisabilité : comment le faire par héritage
Class AC Class NC extends AC
{ {
… …
public void f1(…) public void g1(…)
public voi public void g2(…)
d f2(…) }
}
 NC ref = new NC(…)

 ref.f1(); // la fille réutilise les opérations de la
classe AC
3
17/11/2020
Adaptateur (par héritage)
Adaptateur
 Target –Interface
 Définit l’interface utilisée par les clients
 Client
 Utilise des objets conformes à l’interface Target
 Adaptee
 Définit une interface existante qui exige une adaptation
 Adapter
 Adapte l’interface d’Adaptee à l’interface Target
4
17/11/2020
La composition et ses principes
 Notation : le nouvel objet sera appelé objet composé.

 La composition est définie dynamiquement à l'exécution
 L'accès des objets (composants) entrant dans la
composition se fait par l'intermédiaire d'une de leurs
interfaces.
 L'encapsulation des composants est totalement
respectée
 A l'exécution, chaque composant peut être remplacé
par un autre composant pourvu que le nouveau
composant contienne l'interface utilisée.
 Il faut que les composants contiennent les interfaces
utilisées dans l'objet composé
Réutilisation par composition

Class AC Class NC
{ {
… AC oac
public voidf1(…) Public NC() {
} oac= new AC();
}
public voidf1(…)
{
oac.f1(…)
}
public voidg1(…)
}
NC ref = new NC(…)ref.f1(); // ref réutilise les opérations de la classe

AC
5
17/11/2020
Adaptateur (par composition)
Adaptateur
6
17/11/2020
Exemple
Exemple 2
 Au cours de la vie d’un logiciel, certaines classes sont
susceptibles de voir leur contrat vis-à-vis de l’extérieur
profondément modifié (changement de la signature de
méthodes, suppression de méthodes, etc.). Pour gérer ces
modifications de contrat, deux stratégies sont possibles :
 Modifier l’ensemble des classes utilisatrices, ce qui peut
s’avérer rapidement rédhibitoire.
 Chercher à rester parfaitement compatible avec les anciens
contrats, d’où une complexité accrue de la classe au fil des
évolutions.
 Le design pattern adaptateur permet de maintenir différentes
versions d’une même classe au sein d’un logiciel. Pour cela, il
suffit de créer une classe par version.
7
17/11/2020
8
17/11/2020
Patron de structure
Façade
 Intention
 Fournir une interface unique, simplifiée ou unifiée, pour
accéder à un ensemble d’interfaces d’un sous-système
complexe.
 Exemple
 Réduire la complexité d’un système en le découpant en
plusieurs sous-systèmes ET éviter la dépendance entre les
clients et les éléments du sous-système
 Principe des entrepôts de données
Patron de structure
Façade
 Fournir une interface unique pour un système complexe
 Séparer un sous-système de ses clients
 Découper un système en couches (une façade par point d’entrée

dans chaque couche)
9
17/11/2020
Patron de structure
Façade
 Structure
 La Façade connaît quelles classes du sous-système sont
responsables de telle ou telle requête, et délègue donc les
requêtes aux objets appropriés
 Les classes sous-jacentes à la façade implémentent les
fonctionnalités
 Le nombre de classes n’est pas limité
 Les clients manipulent le sous-système en s’adressant à la
façade (ou aux éléments du sous-système rendus publics par
la façade)
 La façade transmet les requêtes au sous-système après
transformation si nécessaire
Patron de structure
Façade
 Conséquences
 Facilite l’utilisation par la simplification de l’interface
 Diminue le couplage entre le client et le sous-système
 Ne masque pas forcément les éléments du sous-système (un
client peut utiliser la façade ou le sous-système)
 Permet de modifier les classes du sous-système sans affecter
le client
 Peut masquer les éléments privés du sous-système
 L’interface unifiée présentée par la façade peut être trop
restrictive
10
17/11/2020
11
17/11/2020
12
17/11/2020
Comparaison façade et adaptateur
 De prime abord, ces deux patterns semblent similaires : ils

impliquent tous les deux une ou plusieurs classes existantes n’ayant
pas l’interface voulue et la création d’un objet avec cette
interface souhaitée
même si tous deux ont un rôle d’encapsulation, leur méthode d’encapsulation diffère
les deux patterns utilisent des classes préexistantes ;

• contrairement au pattern Adaptateur, le pattern Façade n’implique pas
la prise en compte d’une interface spécifique lors de la conception ;
• le polymorphisme n’intervient pas dans la façade, alors qu’il est utile
dans l’adaptateur, sauf si vous devez simplement concevoir une API
spécifique ;
• le pattern Façade a pour but de simplifier l’interface tandis que
l’adaptateur cherche d’abord à concevoir une solution pour une interface
existante.
 une façade simplifie une interface alors qu’un adaptateur la
convertit en une interface préexistante
13
17/11/2020
Patron de structure
Bridge
 Intention
 Découple l’abstraction (interface) de l’implémentation afin de permettre
aux deux de varier indépendamment
 Partager une implémentation entre de multiples objets
 Exemple
 MVC: découplage entre les facettes (interfaces de communications)
 Permet de développer des représentations interchangeables
 Structure
 Programmation par deux interfaces
 Conséquence
 Modularité, indépendance, réutilisation
 Masquer les détails d’un côté à l’autre
Birdge
14
17/11/2020
Exemple
RedColor
abstract class Shape {

Color color;
Shape(Color color)
{ this.color=color; }
abstract public void colorIt();
}
Proxy
 Contexte
 Le client a besoin d’accéder aux services d’un autre composant (ex. objet, base
de données, page html ou image)
 L’accès direct est possible du point de vue technique mais sans être la
meilleure solution
 Problème
 Objet distant. L’utilisation de ses services présuppose l’initialisation d’une
communication via un protocole spécifique (RMI, IIOP, SOAP, etc.).
 Accès contrôlés à l’objet. La sécurité du logiciel s’impose à certains objets
critiques, et l’appel de leurs méthodes est conditionné par un niveau
d’autorisation suffisant.
 Objet coûteux à instancier. Une stratégie de création des instances est
nécessaire
 Solution
 Le client communique avec le représentant (proxy) plutôt qu’avec le composant
 Le proxy offre l’interface du composant mais exécute des procédures
additionnelles avant (pre) et après (post) l’invocation du composant
15
17/11/2020
Proxy
Proxy
 Proxy
 Offre aux clients l’interface de l’Original
 Assure l’accès sécurisé, efficace et correct à l’Original
 AbstractOriginal
 Définit l’interface (ou la classe de base) pour l’Original et le Proxy
 Ainsi, le Proxy peut être utilisé à tout endroit où l’Original est attendu
 Original
 Implémente les services décrits dans l’AbstractOriginal
 Définit l’objet réel représenté par le Proxy
 Client
 Utilise l’interface du Proxy pour requérir les services de l’Original
16
17/11/2020
Proxy
17
17/11/2020
Exemples
 Proxy distant
 Est le représentant local d’un objet situé dans un autre espace
d’adressage
 Ex: le Stub de RMI, CORBA, Java EE, .NET, …
Exemples
Proxy virtuel
Crée des objets coûteux à la demande (lazyloading, caching,
…)
Ex: reporter la création d’un client email jusqu’à la première
utilisation
Ex: utiliser un cache local d’images
Proxy de protection
Contrôle l’accès au composant (plusieurs droits d’accès sont
possibles)
ex: Serveur d’Application –le traitement d’une requête client
n’est pas démarré si les droits d’accès du client sont
insuffisants
18
17/11/2020
Patron de structure
Composite
 Intention
 Composer des objets dans des structures d’arbre pour
représenter des hiérarchies composants/composés
 Composite permet au client de manipuler uniformément les
objets simples et les objets au sein de leurs compositions
 Exemple
 JComponent / JButton, JLabel, etc. ou java.awt.Component
/ java.awt.Container
Patron de structure
Composite
 Une classe abstraite qui représente à la fois les
primitives (contenues) et les containers
 Représentation de hiérarchie composants / composés
 Les clients doivent ignorer la différence entre les objets

simples et leurs compositions (uniformité apparente)
19
17/11/2020
Patron de structure
Composite
Abstract Windowing Toolkit (AWT)
20
17/11/2020
Patron de structure
Composite
 Structure
 Component (java.awt.Component)
 déclare l’interface commune à tous les objets
 implémente le comportement par défaut pour toutes les classes si
nécessaire
 déclare l’interface pour gérer les composants fils
 Définit l’interface pour accéder au composant parent (optionnel )
 Leaf représente une feuille (java.awt.Button)
 Implémentation du comportement
 Composite (java.awt.Container) définit le comportement des composants
ayant des fils, stocke les fils et implémente les opérations nécessaires à
leur gestion
 Lien dans la hiérarchie
 Comportement : fusion des comportements des fils
 Les clients (affichage graphique) utilise l’interface Component, si le
receveur est une feuille la requête est directement traitée, sinon le
Composite retransmet habituellement la requête à ses fils en effectuant
éventuellement des traitements supplémentaires avant et/ou après
Composite (exemple)
21
17/11/2020
Composite (exemple)
Composite (exemple)
22
17/11/2020
Exemple : expression
Nombre expression
Addition
Exemples
 Une Expression de type composite (Expression)
• Expression e = new Addition(new Nombre(1),new
Nombre(3));
 Une Expression de type composite (API AWT)
• Container p = new Panel();

• p.add(new Button("b1"));
• p.add(new Button("b2"));
23
17/11/2020
Patron de structure
Décorateur
 Intention
 Attacher dynamiquement des capacités additionnelles à un
objet
 Fournir ainsi une alternative flexible à l’héritage pour
étendre les fonctionnalités
 Pour ajouter des capacités de manière transparente
 Pour des capacités qui peuvent être retirées
 Quand l’extension par héritage produirait un nombre
trop important d’extensions indépendantes
 Quand l’héritage est interdit
Patron de structure
Décorateur
24
17/11/2020
Décorateur
 La classe abstraite Composant définit le point de départ de ce diagramme.
 Plusieurs ComposantConcret peuvent hériter de Composant
 décorateur: une classe abstraite héritant de Composant et ayant un attribut de
type Composant.Decorateur déclare abstraite la méthode dont l’on souhaite
étendre les fonctionnalités.
 Pour ajouter des fonctionnalités à un ensemble de ComposantConcret on va
créer des classes DecorateurConcret qui héritent de Decorateur.
 Un DecorateurConcret contient un constructeur permettant d’initialiser l’attribut
composant présent dans le décorateur.
 la classe DecorateurConcret redéfinisse la méthode déclarée abstraite dans le
décorateur. Lors de cette redéfinition il est possible d’étendre les fonctionnalités
en appelant la méthode de l’attribut composant et en ajoutant des traitements.
Ce pattern utilise largement l’héritage mais il utilise aussi la composition grâce à
l’attribut Composant présent dans le décorateur. C’est l’alliance de ces deux
procédés qui permet à ce pattern d’être si efficace.
Exemple 1
 Un autre exemple : un texte décoré par des balises
HTML
 exemple
25
17/11/2020
Le TexteI, Texte et TexteDécoré

public interface TexteI{
public String toHTML();
}
public class Texte implements TexteI{
private String texte;
public Texte(String texte){this.texte = texte;}
public String toHTML(){return this.texte;}
}
public abstract class TexteDécoré implements TexteI{
private TexteI unTexte;
public TexteDécoré(TexteI unTexte){
this.unTexte = unTexte;
}
public String toHTML(){
return unTexte.toHTML();
}
}
B,I,…
public class B extends TexteDécoré{
public B(TexteI unTexte){
super(unTexte);
}
return "" + super.toHTML() + "";
}
}
public class I extends TexteDécoré{
public I(TexteI unTexte){
super(unTexte);
}
return "" + super.toHTML() + "";
}
}
26
17/11/2020
décoration
 TexteI t = new B( new I( new Texte("Exemple")));
 String s = t.toHTML();
Exemple 2
27
17/11/2020
Exemple3
Exercice
A un distributeur, les clients ont le choix entre 3 types de café :
Colombia (1 D),Expresso (1.2 D) et Deca (0.8D). Ils peuvent ajouter
les suppléments suivants : Lait, Sucre, Caramel, Chantilly. L'ajout de
sucre ou de lait est facturé 0.2 D, de caramel 0.4D et de chantilly
0.8D. Il faut garder à l'esprit que l'ajout futur de nouveaux ingrédients
(café ou supplément) doit être simplifié. On veut afficher dans la
console le prix du café choisi avec ses suppléments.
1) Donner le diagramme de classe modélisant ce distributeur
28
17/11/2020
 Appliquer le patron Décorateur à cet exemple.

Donner le diagramme de classes, préciser
l'implémentation des méthodes, et donner le code
pour afficher le prix d'un Expresso avec sucre, et
d'un Colombia Chantilly Caramel.
29
17/11/2020
Poids-mouche (flyweight)
 Intention
- Utilise une technique de partage permettant la mise en œuvre efficace d’un

grand nombre d’objets de granularité fine.
- Lorsque de nombreux (petits) objets doivent être manipulés, mais qu'il serait
trop coûteux en mémoire s'il fallait instancier tous ces objets, il est judicieux
d'implémenter le poids-mouche.
 Exemple
pour représenter des caractères ou des icônes à l'écran, ce type de patron de
conception est apprécié. Ainsi, chaque caractère peut être représenté par une
instance d'une classe contenant sa police, sa taille, etc. La position des
caractères à afficher est stockée en dehors de cette classe. Ainsi, on a une
seule instance de la classe par (type de) caractère et non une instance par
caractère affiché à l'écran.
30
17/11/2020
Structure
Structure
 RESPONSABILITES :
 PoidsMouche : déclare l'interface permettant à l'objet de recevoir et d'agir en
fonction de données extrinsèques. On externalise les données extrinsèques d'un
objet PoidsMouche afin qu'il puisse être réutilisé.
 ConcretePoidsMouche : implémente l'interface poids-mouche. Les informations
contenues dans un ConcretePoidsMouche sont intrinsèques (sans lien avec son
contexte). Puisque, ce type de poids-mouche est obligatoirement partagé.
 ConcretePoidsMoucheNonPartage : implémente l'interface poids-mouche. Ce type
de poids-mouche n'est pas partagé. Il possède des données intrinsèques et
extrinsèques.
 PoidsMoucheFabrique : fournit une méthode retournant une instance
de PoidsMouche. Si les paramètres de l'instance souhaitée correspondent à
un PoidsMouche partagé, l'objet PoidsMoucheFabrique retourne une instance déjà
existante. Sinon l'objetPoidsMoucheFabrique crée une nouvelle instance.
 La partie cliente demande à PoidsMoucheFabrique de lui fournir un PoidsMouche.
31
17/11/2020
Exemple
Dans un logiciel de DAO
Le trait a une épaisseur (simple ou double), une continuité (continu, en pointillé), une
ombre ou pas, des coordonnées. Les caractéristiques d'épaisseur, de continuité et
d'ombre sont des attributs intrinsèques à un trait, tandis que les coordonnées sont des
attributs extrinsèques. Plusieurs traits possèdent des épaisseurs, continuité et ombre
similaires. Ces similitudes correspondent à des styles de trait.
 En externalisant les attributs intrinsèques des objets (style de trait), on peut avoir en
mémoire une seule instance correspondant à un groupe de valeurs (simple-continu-
sans ombre, double-pointillé-ombre).
 Chaque objet avec des attributs extrinsèques (trait avec les coordonnées) possède
une référence vers une instance d'attributs intrinsèques (style de trait). On obtient
deux types de poids-mouche : les poids-mouche partagés (style de trait) et les poids-
mouche non partagés (le trait avec ses coordonnées).
 La partie cliente demande le poids-mouche qui l'intéresse à la fabrique de poids-
mouche. S'il s'agit d'un poids-mouche non partagé, la fabrique le créera et le
retournera. S'il s'agit d'un poids-mouche partagé, la fabrique vérifiera si une instance
existe. Si une instance existe, la fabrique la retourne, sinon la fabrique la crée et la
retourne.
32
15/12/2020
Les patterns de comportement

- Fournir des solutions pour distribuer les traitements et
les algorithmes entre les objets
- Organisent les objet et leurs interactions en spécifiant
le flux de contrôle et de traitement au sein d’un système
d’objets
Les patterns de comportement

 Deux types de motifs :
 Motifs de comportement de classes : utilisation de l'héritage
pour répartir les comportements entre des classes (ex :
Interpreter)
 Motifs de comportement d'objets avec l'utilisation de
l'association entre objets :
 pour décrire comment des groupes d'objets coopèrent (ex :
Mediator)
 pour définir et maintenir des dépendances entre objets (ex :
Observer)
 pour encapsuler un comportement dans un objet et déléguer les
requêtes à d'autres objets (ex : Strategy, State, Command)
 pour parcourir des structures en appliquant des comportements
(ex :Visitor, Iterator)
1
15/12/2020
Exemple introductif
 Dans de nombreuses situations il faut choisir un algorithme au sein
d'une famille afin de traiter au mieux la situation courante.
Prenons, par exemple, un problème classique de tri de liste.
 méthode pour chacun des algorithmes de tri

 utiliser des structures conditionnelles pour choisir le bon type
d'algorithme a un moment donné
Patron de comportement
Pattern Strategy
4
 Au sein d’une classe, le traitement effectué par une ou plusieurs

méthodes données peut fortement varier en fonction du contexte.
Cela a pour conséquence d’obscurcir le contenu de la méthode en
mêlant traitement et tests pour identifier le contexte dans lequel
l’objet se situe.
 Intention
 Définir une hiérarchie de classes pour une famille d'algorithmes,
encapsuler chacun d'eux, et les rendre interchangeables
 Les algorithmes varient indépendamment des clients qui les utilisent
2
15/12/2020
Pattern Strategy
Pattern Strategy
3
15/12/2020
Pattern Strategy
7
 Structure
 Contexte: maintient une référence à l’objet Strategy. Il peut définir une
interface qui permet à l’objet Strategy d’accéder à ses données
 Stratégie: déclare une interface commune à tous les algorithmes
 ConcreteStrategy implémente l’algorithme en utilisant l’interface
Strategie
 Déroulement
 Le Contexte envoie les requêtes de ses clients à l’une de ses stratégies.
 Les clients créent la classe concrète qui implémente l’algorithme.
 Puis ils passent la classe au Contexte.
 Enfin ils interagissent avec le Contexte exclusivement.
Pattern Strategy
8
 Lorsque de nombreuses classes associées ne diffèrent
que par leur comportement
 Lorsqu’on a besoin de plusieurs variantes d’un
algorithme
 Lorsqu’un algorithme utilise des données que les clients
ne doivent pas connaître
 Lorsqu’une classe définit plusieurs comportements
4
15/12/2020
Application: pattern Strategy
Exemple : pattern strategy
5
15/12/2020
Exemple: pattern strategy

 public interface IBehaviour {
public int moveCommand();  public class DefensiveBehaviour implements
} IBehaviour{
public int moveCommand()
public class AgressiveBehaviour {
implements IBehaviour{
public int moveCommand() System.out.println("\tDefensive
{ Behaviour: if find another robot run from it");
System.out.println("\tAgressive return -1;
Behaviour: if find another robot attack it"); }
return 1; }
}
} public class NormalBehaviour implements
IBehaviour{
public int moveCommand()
{
System.out.println("\tNormal
Behaviour: if find another robot ignore it");
return 0;
}
}
Exemple: pattern Strategy

 public void move()
 public class Robot { {
IBehaviour behaviour; System.out.println(this.name + ":
String name; Based on current position" +
public Robot(String name) "the behaviour object decide the next move:");
{ int command =
behaviour.moveCommand();
this.name = name; // ... send the command to
} mechanisms
System.out.println("\tThe result
public void setBehaviour(IBehaviour returned by behaviour object " +
behaviour)
{ "is sent to the movement mechanisms " +
this.behaviour = behaviour; " for the robot '" + this.name + "'");
} }
public String getName() {
public IBehaviour getBehaviour() return name;
}
{
return behaviour; public void setName(String name) {
} this.name = name;
}
}
6
15/12/2020
Template method (patron de méthode)
 Définir le squelette d’un algorithme en déléguant

certaines étapes à des sous-classes
 Une classe possède un fonctionnement global. Mais les
détails de son algorithme doivent être spécifiques à
ses sous-classes.
Template method
7
15/12/2020
Template method
 AbstractClasse : définit des méthodes abstraites
primitives. La classe implémente le squelette d'un
algorithme qui appelle les méthodes primitives.
 ConcreteClasse : est une sous-classe concrète de
AbstractClasse. Elle implémente les méthodes utilisées
par l’algorithme de la méthode
TemplateMethod() de AbstractClasse.
 La partie cliente appelle la méthode
de AbstractClasse qui définit l'algorithme.
Exemple
 cas d'un document informatique: le document a
un fonctionnement global où il est sauvegardé.
Pour la sauvegarde, il y aura toujours besoin
d'ouvrir le fichier, d'écrire dedans, puis de fermer
le fichier. Mais, selon le type de document, il ne
sera pas sauvegardé de la même manière. S'il
s'agit d'un document de traitement de texte, il
sera sauvegardé en suite d'octets. S'il s'agit d'un
document HTML, il sera sauvegardé dans un
fichier texte.
8
15/12/2020
Template method
Template method
 Exemple
9
15/12/2020
Template Method
 Différence entre patrons Strategie et Template Method :
 Le patron Strategie encapsule une famille d'algorithmes dans
des objets, permettant à l'utilisateur d'utiliser et d'ajouter des
algorithmes facilement.
 Le patron Template method définit le squelette d'un algorithme
dont certaines parties sont implémentées différemment par les
sous-classes. La methode templateMethode contrôle la structure
de l'algorithme. Ceci permet de :
 Supprimer la duplication du code et maximiser sa réutilisation
 La mise a jour d'un bout de code se fait a une seule place.
 Contrôle des extensions permises aux sous-classes.
Chaîne de Responsabilités
 Eviter le couplage entre l’expéditeur d’une requête

et son destinataire en donnant à plusieurs objets la
possibilité de traiter la requête.
 Chaîner les objets traitants et faire passer la
requête à travers ces objets jusqu’à ce qu’elle soit
traitée.
10
15/12/2020
 Contexte
 Le système doit traiter une requête
 La requête peut être traitée de plusieurs façons (par plusieurs
objets)
 Problème
 Différents objets peuvent traiter une requête et on ne sait pas a
priori lequel
 L'ensemble des objets pouvant traiter une requête doit être
facilement modifiable
 Solution
 Isoler les différents parties d’un traitement dans différents
objets
 Faire passer la requête via une chaîne d’objets (maillons)
 Chaque maillon peut traiter la requête et/ou la faire passer au
maillon suivant
Chaîne de responsabilités
11
15/12/2020
Chaîne de responsabilités: exemple

 Le directeur s'occupe des achats. S'ils sont inferieurs à 100D, il peut
donner son accord. S'ils sont supérieurs a 100D mais inferieurs à
100000D, il faut l'accord du vice-président. Au delà, il faut l’accord du
président
 Exemples
 Transformer un fichier XML a besoin de plusieurs filtres : traiter
du code , des images, des liens…
 Les besoins sont les suivants :
 Plusieurs filtres permettant de remplacer le contenu original par un
nouveau contenu
 Pouvoir enchaîner les filtres dynamiquement
 Pouvoir ajouter un filtre en cas d'oubli ou de nouveau besoin
  le pattern chaine de responsabilités peut être la solution
 Un code client cherche une personne. Ce code client est en

relation avec plusieurs moyens de recherche afin de la trouver.
Comment profiter de ces moyens de recherches afin de trouver
la personne en question?
12
15/12/2020
Exemples
 Interface IMoyenDeRecherche {
public function trouve ($personne);
}
 class PagesJaunes implements IMoyenDeRecherche
{/**/}
 class Internet implements IMoyenDeRecherche
{/**/}
Etat (State)
26
13
15/12/2020
Etat (State)
Etat (Stat)
niveauCournat : Etat
14
15/12/2020
Etat (State)
Exemple(1/2)
15
15/12/2020
Exemple(2/2)
Etat (state)
 Le pattern State permet de :
 simplifier l'ajout et la suppression d'un Etat
 supprimer des traitements conditionnels de grande
taille
 Rendre les transitions entre états explicites
16
15/12/2020
Exemple : Etat
Observer
 Problème : Comment faire savoir a un ensemble d'objets
(observateur/abonne/observer) qu'un autre objet
(observé/sujet/publieur/observable) dont ils dépendent a été
modifié?
17
15/12/2020
Observer
observer
18
15/12/2020
Observer
Exemple: observer
19
15/12/2020
Command
39
 Intention
 Encapsuler une requête comme un objet
 Permettre de défaire des traitements (undo)
 But
 Découpler la réception d'une requête de son exécution
 Contexte
 Réaliser un traitement sans avoir besoin de savoir de quoi il
s'agit et de qui va l'exécuter
 Découpler les objets qui invoquent une action de ceux qui
l'exécutent
Command
Structure
20
15/12/2020
Command
41
 Le client crée l’objet

ConcreteCommand et spécifie
le destinataire.
 L’objet Invoker stocke l’objet

ConcreteCommand.
 L’objet Invoker émet une requête

en invoquant “execute” sur la
commande.
 Lorsque la commande est réversible,
ConcreteCommand stoque l’état
nécessaire pour revenir dans l’état
précédant l’invocation de
“execute”.
 L’objet ConcreteCommand
invoque les opérations du
destinataire pour exécuter la
requête.
Command
 Command
 déclare une interface pour exécuter une opération.
 ConcreteCommand (PasteCommand, OpenCommand)
 Définit une liaison entre l’objet destinataire et l’action
 Implémente “execute” par l’invocation d’ opérations sur le destinataire.
 Client (Application)
 Crée un objet ConcreteCommand et assigne son destinataire.
 Invoker (MenuItem)
 Demande à la commande de s’exécuter.
 Destinataire (Document, Application)
 Sait comment exécuter les opérations associées à la requête.
 N’importe quelle classe peut agir comme destinataire.
21
15/12/2020
command
Exemple: command
22
15/12/2020
Exemple: command
 public interface Order {
public abstract void execute ( );  //ConcreteCommand Class.
} class BuyStockOrder implements Order {
// Receiver class. private StockTrade stock;
public BuyStockOrder ( StockTrade st) {
class StockTrade { stock = st;
public void buy() { }
System.out.println("You want to buy public void execute( ) {
stocks"); stock . buy( );
}
} }
public void sell() {
System.out.println("You want to sell stocks //ConcreteCommand Class.
"); class SellStockOrder implements Order {
private StockTrade stock;
} public SellStockOrder ( StockTrade st) {
} stock = st;
// Invoker. }
class Agent { public void execute( ) {
stock . sell( );
private m_ordersQueue = new ArrayList(); }
public Agent() { } }
void placeOrder(Order order) {
ordersQueue.addLast(order);
order.execute(ordersQueue.getFirstAndRemov
e());
}
Exemple : command
 // Client
public class Client {
public static void main(String[]
args) {
StockTrade stock = new
StockTrade();
BuyStockOrder bsc = new
BuyStockOrder (stock);
SellStockOrder ssc = new
SellStockOrder (stock);
Agent agent = new Agent();
agent.placeOrder(bsc);
agent.placeOrder(ssc);
}
}
23
15/12/2020
Mémento
Sauvegarder l'état interne d'un objet en respectant
l'encapsulation, afin de le restaurer plus tard.
 Intention
 Extrairel’état d’un objet

 Restaurer cet état sans violer l'encapsulation
 Permettre à l'utilisateur
 de revenir en arrière
 pour se reconstituer après des erreurs.
Mémento
24
15/12/2020
Mémento
Mémento
25
15/12/2020
Mémento
 EXEMPLE
 un éditeur de document disposant d'une fonction
d'annulation. La fonction d'annulation est sur plusieurs
niveaux.
 Les informations de l'état interne (état du document) sont
conservées dans un mémento. L'objet avec l'état interne
(document) est le créateur du mémento. Afin de respecter
l'encapsulation, les valeurs du mémento ne sont visibles que
par son créateur. Ainsi, l'encapsulation de l'état interne est
préservée. Un autre objet est chargé de conserver les
memento (gestionnaire d'annulation) : il s'agit du gardien.
itérateur
 Fournir un moyen de parcourir séquentiellement les éléments

d'un objet composé.
 Le système doit parcourir les éléments d'un objet complexe.
La classe de l'objet complexe peut varier.
 Cela est le cas des classes représentant des listes et des
ensembles en Java.
 Les classes d'un objet complexe (listes) sont des "composes".
Elles ont une méthode retournant un itérateur, qui permet de
parcourir les éléments. Tous les itérateurs ont la même
interface Ainsi, le système dispose d'un moyen homogène de
parcourir les composes.
26
15/12/2020
Itérateur
Itérateur
 Compose : définit l'interface d'un objet composé permettant de
créer un Iterateur.
 ConcreteCompose : est une sous-classe de l'interface Compose. Elle
est composée d'éléments et implémente la méthode de création
d'un Iterateur.
 Iterateur : définit l'interface de l'itérateur, qui permet d'accéder aux
éléments de l'objet Compose.
 ConcreteIterateur : est une sous-classe de l'inteface Iterateur. Elle
fournit une implémentation permettant de parcourir les éléments
de ConcreteCompose. Elle conserve la trace de la position courante.
 La partie cliente demande à l'objet Compose de fournir un
objet Iterateur. Puis, elle utilise l'objet Iterateur afin de parcourir les
éléments de l'objet Compose.
27
15/12/2020
Exemple
Itérateur
28
15/12/2020
Visitor
57
 Intention
 Représenter UNE opération à effectuer sur les éléments
d’une structure
 Permet de définir une nouvelle opération sans changer les
classes des éléments sur lesquels on opère
 Exemple
 Un arbre de syntaxe abstraite pour un compilateur, un outil
XML…Différents traitement sur le même arbre : type check,
optimisation, analyses…
Visitor
58
 Une structure contient beaucoup de classes aux
interfaces différentes
 Les classes définissant la structure changent peu, mais
de nouvelles opérations sont toujours nécessaires
 éviter la pollution des classes de la structure
29
15/12/2020
Visitor
60
 Structure
 ObjectStructure (le programme demandeur) peut
énumérer ses éléments de type Element et peut être un
Composite
 Element définit une opération accept qui prend un
Visitor en paramètre
 ConcreteElement implémente l’opération accept
30
15/12/2020
Visitor
61
 Structure
 Visitor
 déclare l’opération de visite pour chaque classe de ConcreteElement
dans la structure
 La signature (et le nom) de l’opération identifie la classe qui envoie la
requête de visite au visiteur. Le visiteur détermine alors la classe
concrète et accède à l’élément directement
 ConcreteVisitor
 Implémente chaque opération déclarée par Visitor
 Chaque opération implémente un fragment de l’algorithme, et un état
local peut être stocké pour accumuler les résultats de la traversée de
la structure
Visitor
62
 Déroulement
 Un objectStructure parcours ses éléments (différentiation selon le type possible) et
envoie le visiteur (elt.accept(visiteur))
 Les éléments appelent (à tour de rôle) l’opération du visiteur (visiteur.visit(this))
 Le visiteur agrège les données aux travers d’appel de méthode des éléments
(paramètres de visit)
31
15/12/2020
Visitor
63
 Conséquences
 Ajout de nouvelles opérations très facile
 Groupement/séparation des opérations communes
 Ajout de nouveaux ConcreteElement complexe (opération
dépendant du type…)
 Visitor traverse des structures où les éléments sont de types
complètement différents / Iterator
 Accumulation d’état dans le visiteur plutôt que dans des
arguments
 Suppose que l’interface de ConcreteElement est assez riche
pour que le visiteur fasse son travail => cela force à
montrer l’état interne et à casser l’encapsulation
Exemple (sans visiteur)
32
15/12/2020
33
15/12/2020
Avec Visiteurs
34
15/12/2020
Exemple avec Visiteur
Exemple avec Visiteur(1)
35
15/12/2020
36
15/12/2020
Figures avec Visiteurs
Draw
Draw
37
15/12/2020
Médiateur
 Au fur et à mesure que l’on ajoute des classes complexes à
une application, la communication entre plusieurs classes
complexes devient difficile à gérer
 Le couplage entre les classes devient plus important
 Ce patron cherche à pallier ce problème avec la conception
d’une classe «médiatrice» qui, elle seule, connaît la
complexité de chaque classe.
 Les classes complexes se communiquent entre elles à travers
la classe médiatrice.
Gérer la transmission d'informations entre des objets interagissant entre
eux.
 Avoir un couplage faible entre les objets puisqu'ils n'ont pas de lien
direct entre eux.
 Pouvoir varier leur interaction indépendamment.
médiateur
 Différents objets ont des interactions. Un événement sur
l'un provoque une action ou des actions sur un autre ou
d'autres objets.
 Cela peut être les éléments d'IHM. Si une case est
cochée, certains éléments deviennent accessibles. Si une
autre case est cochée, des couleurs de l'IHM changent.
 Si les classes communiquent directement, il y a un
couplage très fort entre elles. Une classe dédiée à la
communication permet d'éviter cela. Chaque élément
interagissant (élément de l'IHM) sont des collègues. La
classe dédiée à la communication est un médiateur.
38
15/12/2020
Médiateur : Intension
Médiateur
39
15/12/2020
Médiateur
 Collegue : définit l'interface d'un collègue. Il s'agit
d'une famille d'objets qui s'ignorent entre eux mais qui
doivent se transmettre des informations.
 ConcreteCollegueA et ConcreteCollegueB : sont des
sous-classes concrètes de l'interface Collegue. Elles ont
une référence sur un objet Mediateur auquel elles
transmettront les informations.
 Mediateur : définit l'interface de communication entre
les objets Collegue.
 ConcreteMediateur : implémente la communication et
maintient une référence sur les objets Collegue.
 Programme principal crée le médiateur

 Passe le médiateur à tous les collègues dans leur
constructeur
 CopyButton, KidList, KTextField, etc.
 Chaque collègue s’inscrit chez le médiateur
40
15/12/2020
Avant le médiateur
41
15/12/2020
Après le médiateur
 Les éléments de l’UI doivent communiquer directement

avec l’objet médiateur.
Exemple de médiateur : mise à jour depuis une vue
 les différents objets « vue » ne sont pas en interaction ; ils ne référencent

que le médiateur (Controller)
42
15/12/2020
Liens avec les autres patrons
 La Chaîne de responsabilité, la Commande,

le Médiateur et l’Observateur proposent différentes
solutions pour associer les demandeurs et les récepteurs.
 La chaîne de responsabilité envoie une demande ordonnée qui est
passée tout au long d’une chaîne dynamique de récepteurs
potentiels, jusqu’à ce que l’un d’entre eux décide de la traiter.
 La commande établit des connexions unidirectionnelles entre les
demandeurs et les récepteurs.
 Le médiateur élimine les liens directs entre les demandeurs et les
récepteurs, et les force à communiquer indirectement via un objet
médiateur.
 L’observateur permet aux récepteurs de s’inscrire et de se
désinscrire dynamiquement à la réception des demandes.
Façade vs Médiateur
 La Façade et le Médiateur ont des rôles similaires :
ils essayent de faire collaborer des classes
étroitement liées.
 La façade définit une interface simplifiée pour un sous-
système d’objets, mais elle n’ajoute pas de nouvelles
fonctionnalités. Le sous-système est conscient de
l’existence de la façade. Les objets situés à l’intérieur
du sous-système peuvent communiquer directement.
 Le médiateur centralise la communication entre les
composants du système. Les composants ne voient que
l’objet médiateur et ne communiquent pas directement.
43
15/12/2020
Médiateur vs Observateur
 La différence entre le Médiateur et l’Observateur est souvent
très fine.
 Le but principal du médiateur est d’éliminer les dépendances
mutuelles entre un ensemble de composants du système. À la
place, ces composants peuvent devenir dépendants d’un
unique objet médiateur. Le but de l’observateur est d’établir
des connexions dynamiques à sens unique entre les objets, où
certains objets peuvent être les subordonnés d’autres objets.
 Il existe une implémentation populaire du médiateur qui
repose sur l’observateur. L’objet médiateur joue le rôle du
diffuseur et les composants agissent comme des souscripteurs
qui s’inscrivent et se désinscrivent des événements du
médiateur. Lorsque ce type de conception est mis en place,
le médiateur ressemble de près à l’observateur.
44

UML All in One

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UML All in One

Încărcat de

Drepturi de autor:

Formate disponibile

20/10/2020

Les patterns GoF

La conception Orientée objet

 Quel est le secret ?

La conception Orientée objet

 C’est un moyen de partager la connaissance de la résolution

 Un design pattern décrit une structure commune et

Exemple « mauvaise » cohésion

Exemple: « bonne » cohésion

Les design Patterns GoF

Catégories de Design Patterns

 Fabrication (Factory Method)

Catégories de Design Patterns

Catégories de Design Patterns

1 Design patterns de création

•On ne sait pas à l'avance ce qui sera créé ou comment

 Construire un pseudo constructeur

Pattern Factory: présentation

 Les langages oo fournissent des mécanismes d’instanciation et d’initialisation(new,

 La fabrique rend abstraite, pour le client, la création et l’initialisation du produit.

Factory Method : présentation

Factory Method : diagramme

Factory Method: structure

Factory Method: conséquences

Factory Method :implementation

Abstract Factory : présentation

Abstract Factory: utilisation

Abstract Factory : diagramme

Abstract Factory : structure

Abstract Factory: collaboration

Abstract Factory :conséquences

 Encouragement de la cohérence entre les produits

 Prise en compte difficile de nouvelles formes de produit

Abstract Factory : implémentation

 Le Client a besoin de convertir un doc du RTF au format

/*converts a character to target representation and appends to

//This class abstracts the document object

Exemple d’implémentationn de la classe

/* Produit */ class Pizza { private String pate = "";

Exemple d’implémentationn de la classe

/* Monteur */ abstract class MonteurPizza

Exemple d’implémentationn de la classe

/* MonteurConcret */ class MonteurPizzaHawaii

Exemple d’implémentation de la classe

/* Directeur */ class Serveur {

Exemple d’implémentation de la classe

/* Un client commandant une pizza. */ class ExempleMonteur {

Design patterns de structure

L'héritage et ses principes

 Il est défini de façon statique à la compilation

Réutilisation par héritage

 NC ref = new NC(…)

Adaptateur (par héritage)

La composition et ses principes

 Notation : le nouvel objet sera appelé objet composé.

Réutilisation par composition

NC ref = new NC(…)ref.f1(); // ref réutilise les opérations de la classe

Adaptateur (par composition)

 Découper un système en couches (une façade par point d’entrée

Comparaison façade et adaptateur

 De prime abord, ces deux patterns semblent similaires : ils

les deux patterns utilisent des classes préexistantes ;

abstract class Shape {