Quelques patrons de structure

M. Blay-Fornarino & P. Collet 1

 Quelques patrons de Structure
Objectif
Création Structure Comportement
Portée Classe Factory Adapter Interpreter
Method Template Method
Objet Abstract Adapter Chain of Responsibility
Factory Bridge Command
Builder Composite Iterator
Prototype Decorator Mediator
Singleton Facade Memento
Flyweight Observer
Proxy State
Strategy
Visitor
M. Blay-Fornarino & P. Collet 2
 Quelques patrons de Structure
Objectif
Création Structure Comportement
Portée Classe Factory Adapter Interpreter
Method Template Method
Objet Abstract Adapter Chain of Responsibility
Factory Bridge Command
Builder Composite Iterator
Prototype Decorator Mediator
Singleton Facade Memento
Flyweight Observer
Proxy State
Strategy
Visitor
M. Blay-Fornarino & P. Collet 3
 Image : https://www.javagists.com/adapter-design-pattern
Adapter is a structural
design pattern that
allows objects with
incompatible interfaces
to collaborate.

Design Pattern Adaptator

/Adaptateur
https://www.tutorialspoint.com/design_pattern/adapter_pattern.htm
4
 DP Adapter : le
problème au travers
d’un exemple

M. Blay-Fornarino & P. Collet

5
 DP Adapter : le problème
au travers d’un exemple

Mais nous ne pouvons pas modifier

les codes de Tank et Robot !

M. Blay-Fornarino & P. Collet

6
 On a défini un public interface Avatar {
//Renvoie un nombre de
jeu dans lequel Points
des avatars int attaquer();
void avancer();
public class Game{
peuvent void affecterJoueur();
Avatar avatar;
int play () { avatar.attaquer()};
avancer, être } }
affecté à un public class Personnage implements Avatar{
joueur, ou se int attaquer() { …};
void avancer() { …};
battre. void affecterJoueur() {…};
}

On voudrait public class Tank {

//Force du tir
pouvoir utiliser des public int tirer() {… }
objets présents
public void rouler(int vitesse, Direction d) {…
dans un autre jeu. }
}

public class Robot {

private String maitre;
public void frapper() {..}
public void marcher() {...} Inspiré de :
public void reagirAHumain(String maitre) {
this.maitre = maitre; ..
https://www.youtube.com/
} watch?v=qG286LQM6BU
}
7
 DP Adapter :
la solution au travers
d’un exemple

M. Blay-Fornarino & P. Collet

8
 DP Adapter :
la solution au
travers d’un
exemple

9
 DP Adapter
• Intention
– Convertir l’interface d’une classe en une autre interface qui est
attendue par un client.
– Permet de faire collaborer des classes qui n’auraient pas pu le faire
à cause de l’incompatibilité de leurs interfaces
• Synonymes : Wrapper, Mariage de convenance
• Motivation
– Une classe de bibliothèque conçue pour la réutilisation ne peut pas
l’être à cause d’une demande spécifique de l’application
• Champs d’application
– Volonté d’utiliser une classe, même si l’interface ne convient pas
– Création d’une classe qui va coopérer par la suite…
Fréquence :

M. Blay-Fornarino & P. Collet 10

 DP Adapter : Structure
Object adapter
Cette mise en œuvre utilise le principe de la composition d'objets : l'adaptateur met
en œuvre l'interface d'un objet et enveloppe l'autre. Elle peut être mise en œuvre
dans tous les langages de programmation courants.

11
 DP Adapter : structure
• Participants
– Target définit l’interface spécifique à l’application que le client
utilise
– Client collabore avec les objets qui sont conformes à
l’interface de Target
– Adaptee est l’interface existante qui a besoin d’adaptation
– Adapter adapte effectivement l’interface de Adaptee à
l’interface de Target

P. Collet 12
DP Adapter : Comportement

13
 DP Adapter : Structure
Class adapter
Cette mise en œuvre utilise l'héritage : l'adaptateur hérite des interfaces des
deux objets en même temps.

14
 DP Adapter : Implementation(s)
• En Java, utilisation combinée de extends/implements
• Patterns associés
– Bridge, Decorator, Proxy

P. Collet 15
 DP Adapter en résumé
Conséquences (adapter objet)
1. Un adapter peut travailler avec plusieurs Adaptees
2. Plus difficile de redéfinir le comportement d’Adaptee (sous-
classer puis obliger Adapter à référencer la sous-classe)
• Conséquences (adapter classe)
1. Pas possible d’adapter une classe et ses sous-classes
2. Mais redéfinition possible du comportement (sous-classe)

P. Collet 16
 Composite is a
structural design
pattern that lets you
compose objects into
tree structures and
then work with these
structures as if they
were
individual objects.

DP COMPOSITE
17
IMAGE : https://refactoring.guru/design-patterns/
 DP Composite : le problème dans un exemple

https://refactoring.guru/design-patterns 18
 DP Composite : la solution dans un exemple

https://refactoring.guru/design-patterns 19
 DP 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 leurs compositions
• Champs d’application
– Représentation de hiérarchie composants/composés
– Les clients doivent ignorer la différence entre les objets simples et leurs
compositions (uniformité apparente)

Fréquence :

M. Blay-Fornarino & P. Collet 20

 DP Composite : Structure

M. Blay-Fornarino & P. Collet 21

 DP Composite : structure
• Participants
– Component (Graphic)
• 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 (Rectangle, Line, etc.) représente une feuille et définit le comportement
comme tel
– Composite (Picture) définit le comportement des composants ayant des fils,
stocke les fils et implémente les opérations nécessaires à leur gestion
– Client manipule les objets à travers l’interface Component

M. Blay-Fornarino & P. Collet 22

 DP Composite : comportements

M. Blay-Fornarino & P. Collet http://www-sop.inria.fr/axis/cbrtools/usermanual-eng/Patterns/Composite.html 23

 DP Composite : Implementation(s)
– Maximiser l’interface de Component
– Pas de liste de composants dans Component
– Déclarer des opérations de gestion des fils ?
– Ordonnancement des fils => Iterator
– Référence explicite aux parents et Partage des composants ?

• Utilisations connues : Partout !

• Patterns associés
– Chain of Responsibility, Decorator, Flyweight, Iterator, Visitor
M. Blay-Fornarino & P. Collet 24
 DP Composite en résumé
• Collaborations
– Les clients 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
• Conséquences
– Structure hiérarchique, simple, uniforme, général et facile à étendre
pour de nouveaux objets

M. Blay-Fornarino & P. Collet 25

 Quelques patrons de Structure
Objectif
Création Structure Comportement
Portée Classe Factory Adapter Interpreter
Method Template Method
Objet Abstract Adapter Chain of Responsibility
Factory Bridge Command
Builder Composite Iterator
Prototype Decorator Mediator
Singleton Facade Memento
Flyweight Observer
Proxy State
Strategy
Visitor
M. Blay-Fornarino & P. Collet 26
 Decorator is a structural design
pattern that lets you attach new
behaviors to objects by placing
these objects inside special
wrapper objects that contain
the behaviors.

DP DECORATOR
Famille structure

27
IMAGE : https://refactoring.guru/design-patterns/
 DP Decorator : le problème dans un exemple

M. Blay-Fornarino & P. Collet 28

 DP Decorator : le problème dans un exemple

M. Blay-Fornarino & P. Collet 29

 DP Decorator : le problème dans un exemple

M. Blay-Fornarino & P. Collet 30

 DP Decorator : la solution dans un exemple

M. Blay-Fornarino & P. Collet 31

 DP Decorator : la solution dans un exemple

M. Blay-Fornarino & P. Collet 32

 DP Decorator
• Intention
– Attacher dynamiquement des capacités additionnelles à des objets
– Fournir ainsi une alternative flexible à l’héritage pour étendre les
fonctionnalités :
• Le nombre de sous classes serait très grand si on devait définir autant de sous-
classes que de variantes d’une classe
• Certaines classes ne peuvent pas être spécialisées.
• Synonymes : Wrapper (attention !)
• Motivation
– Ajout de capacités pour objet individuellement et dynamiquement
– Englober l’objet existant dans un autre objet qui ajoute les capacités
(plus que d’hériter)
Fréquence :

M. Blay-Fornarino & P. Collet 33

 DP Decorator : Structure

M. Blay-Fornarino & P. Collet 34

 DP Decorator : Structure
• Participants
– Component (VisualComponent) définit l’interface des objets
qui peuvent avoir des capacités dynamiques
– ConcreteComponent (TextView) définit l’objet auquel on peut
attacher de nouvelles capacités
– Decorator maintient une référence à l’objet Component et
définit une interface conforme à ce même Component
– ConcreteDecorator (BorderDecorator, ScrollDecorator) ajoute
les capacités à component
• Collaborations
– Decorator transmet les demandes à son objet Component. Il
peut aussi effectuer du travail en plus avant et après la
transmission

M. Blay-Fornarino & P. Collet 35

 DP Decorator : Comportement
• Structure

M. Blay-Fornarino & P. Collet 36

 DP Decorator : implémentation(s)
• Java : utilisation d’interface pour la conformité
• Pas forcément besoin d’un décorateur abstrait
– Maintenir une classe de base légère
– Decorator est fait pour le changement d’aspect, Strategy est fait
pour le changement radical d’approche

• Utilisations connues
– Organisation de java.io

• Patterns associés
– Adapter, Composite, Strategy
M. Blay-Fornarino & P. Collet 37
 DP Decorator : Component (Code Example)

M. Blay-Fornarino & P. Collet 38

 DP Decorator : Decorator(Code Example)

M. Blay-Fornarino & P. Collet 39

 DP Decorator : usage (Code Example)

M. Blay-Fornarino & P. Collet 40

 DP Decorator en résumé
• Conséquences
1. Plus de flexibilité que l’héritage
2. Évite la surcharge inutile de classe en haut de la hiérarchie
(PAY AS YOU GO)
3. Le décorateur et son composant ne sont pas identiques
4. Plein de petits objets

M. Blay-Fornarino & P. Collet 41

 Quelques patrons de Structure
Objectif
Création Structure Comportement
Portée Classe Factory Adapter Interpreter
Method Template Method
Objet Abstract Adapter Chain of Responsibility
Factory Bridge Command
Builder Composite Iterator
Prototype Decorator Mediator
Singleton Facade Memento
Flyweight Observer
Proxy State
Strategy
Visitor
M. Blay-Fornarino & P. Collet 42
 Facade is a structural design pattern that
provides a simplified interface to a library, a
framework, or any other complex set
of classes.

DP FACADE

43
IMAGE : https://refactoring.guru/design-patterns/
 DP 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.
• Motivation
– Réduire la complexité d’un système en le découpant
en plusieurs sous-systèmes
– Eviter la dépendance entre les clients et les éléments
du sous-système
Fréquence :

P. Collet 44
 Façade (2)

• Champs d’application
– 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)
P. Collet 45
 DP Façade : Structure

P. Collet 46
 DP Façade : Structure
• Participants
– 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é
• Collaborations
– Le client manipule 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

P. Collet 47
 DP Façade : implementations
• Possibilité de réduire encore plus le couplage en créant
une façade abstraite et des versions concrètes
• Les objets de façade sont souvent des singletons
• Utilisations connues
– JDBC…
• Patterns associés
– Abstract Factory, Mediator, Singleton

P. Collet 48
 public abstract class DwarvenMineWorker { case WORK:
work();
public void goToSleep() { break;
LOGGER.info("{} goes to sleep.", name()); default:
} LOGGER.info("Undefined action");
break;
public void wakeUp() { }
LOGGER.info("{} wakes up.", name()); }
}
/**
public void goHome() { * Perform actions.
LOGGER.info("{} goes home.", name()); */
} public void action(Action... actions) {
Arrays.stream (actions).forEach(this::action);
public void goToMine() { }
LOGGER.info("{} goes to the mine.", name());
} public abstract void work();

private void action(Action action) { public abstract String name();

switch (action) {
case GO_TO_SLEEP: enum Action {
goToSleep(); GO_TO_SLEEP, WAKE_UP, GO_HOME, GO_TO_MINE, WORK
break; }
case WAKE_UP:
wakeUp();
break;
case GO_HOME:
goHome();
break;
case GO_TO_MINE:
goToMine(); DP Facade : Service (Code Example)
break;

M. Blay-Fornarino & P. Collet 49

 DP Facade : Services (Code Example)

public class DwarvenGoldDigger extends

DwarvenMineWorker {
..
public class DwarvenTunnelDigger extends
DwarvenMineWorker {

public class DwarvenCartOperator extends @Override

DwarvenMineWorker { public void work() {
//LOGGER.info("{} creates another promising
@Override tunnel.", name());
public void work() { }
LOGGER.info("{} moves gold chunks out of the
mine.", name()); @Override
} public String name() {
return "Dwarven tunnel digger";
@Override }
public String name() { }
return "Dwarf cart operator";
M. Blay-Fornarino & P. Collet 50
}
 public class DwarvenGoldmineFacade {

private final List<DwarvenMineWorker> workers;

DP Facade : Facade (Code Example)
/**
* Constructor.
*/
public DwarvenGoldmineFacade() {
workers = List.of(
new DwarvenGoldDigger(),
new DwarvenCartOperator(),
new DwarvenTunnelDigger());
}

public void startNewDay() {

makeActions(workers,
DwarvenMineWorker.Action.WAKE_UP,
DwarvenMineWorker.Action.GO_TO_MINE);
}

public void digOutGold() {

makeActions(workers,
DwarvenMineWorker.Action.WORK);
}

public void endDay() {

makeActions(workers,
DwarvenMineWorker.Action.GO_HOME,
DwarvenMineWorker.Action.GO_TO_SLEEP);
}

private static void makeActions(

Collection<DwarvenMineWorker> workers,
DwarvenMineWorker.Action... actions
public static void main(String[] args) {
){ var facade = new DwarvenGoldmineFacade();
workers.forEach(worker -> worker.action(actions));
} facade.startNewDay();
}
facade.digOutGold();
facade.endDay();
}
M. Blay-Fornarino & P. Collet 51
 DP Façade en résumé
• Conséquences
1. Facilite l’utilisation par la simplification de l’interface
2. Diminue le couplage entre le client et le sous-système
3. Ne masque pas forcément les éléments du sous-système (un client peut utiliser la
façade ou le sous-système)
4. Permet de modifier les classes du sous-système sans affecter le client
5. Peut masquer les éléments privés du sous-système
6. L’interface unifiée présentée par la façade peut être trop restrictive

P. Collet 52
 Quelques patrons de Structure
Objectif
Création Structure Comportement
Portée Classe Factory Adapter Interpreter
Method Template Method
Objet Abstract Adapter Chain of Responsibility
Factory Bridge Command
Builder Composite Iterator
Prototype Decorator Mediator
Singleton Facade Memento
Flyweight Observer
Proxy State
Strategy
Visitor
M. Blay-Fornarino & P. Collet 53
 Proxy is a structural design
pattern that lets you provide a
substitute or placeholder for
another object. A proxy controls
access to the original object,
allowing you to perform
something either before or after
the request gets through to the
original object.

DP PROXY
Famille Structure

54
IMAGE : https://refactoring.guru/design-patterns/ M. Blay-Fornarino & P. Collet
 DP Proxy : le problème dans un exemple
• L'accès à un objet doit être
contrôlé.
• Des fonctionnalités
supplémentaires doivent être
fournies lors de l'accès à un objet.

Exemples
Si un objet, comme une image volumineuse, met beaucoup de temps
à se charger
Si un objet est situé sur une machine distante
Si un objet a des droits d’accès spécifiques
https://refactoring.guru/design-patterns 55
 DP Proxy : La solution dans un exemple
Définissez un objet Proxy distinct qui peut
être utilisé comme substitut d'un autre
objet (Sujet) et implémente des
fonctionnalités supplémentaires pour
contrôler l'accès à ce sujet.

Pour se substituer à un sujet, un proxy

doit implémenter l'interface du Subjet. Synonyme
Les clients ne peuvent pas dire s'ils Procuration, mandat, surrogate
travaillent avec un sujet ou son proxy.

https://refactoring.guru/design-patterns 56
 DP Proxy
• Intention
– Fournir un substitut afin d’accéder à un autre objet souvent
inaccessible.
– Séparer l ’interface de l’implémentation
• Synonyme
– Procuration, mandat, ambassadeur, surrogate

Fréquence :

M. Blay-Fornarino & P. Collet 57

 DP Proxy : structure

M. Blay-Fornarino & P. Collet 58

 DP Proxy : structure
• Participants
– Proxy maintient une référence qui permet au Proxy d’accéder au
RealSubject. Il fournit une interface identique à celle de Subject, pour
pouvoir se substituer au RealSubject. Il contrôle les accès au RealSubject
– Subject définit une interface commune pour RealSubject et Proxy. Proxy
peut ainsi être utilisé partout où le RealSubject devrait être utilisé
– RealSubject définit l’objet réel que le Proxy représente

M. Blay-Fornarino & P. Collet 59

 DP Proxy : Comportement

M. Blay-Fornarino & P. Collet 60

 DP Proxy : Sujet et sujet concret (Code Example)

M. Blay-Fornarino & P. Collet 61

 DP Proxy : Proxy (Code Example )

M. Blay-Fornarino & P. Collet 62

 DP Proxy : Usage (Code Example)

M. Blay-Fornarino & P. Collet 63

 DP Proxy : applications
• Champs d’application
– Dès qu’il y a un besoin de référencement sophistiqué ou polyvalent, autre qu’un
simple pointeur
– Remote Proxy est un représentant d’un objet situé dans un autre espace
d’adressage
– Virtual Proxy crée des objets « coûteux » à la demande
– Access Proxy contrôle l’accès à un objet
– SmartReference effectue un travail supplémentaire lors de l’accès à l’objet
• Comptage de références (smart pointers)
• Chargement d’objets persistants
• Vérification de non verrouillage

M. Blay-Fornarino & P. Collet 64

 DP Proxy : implementation(s)
• Possibilité de nombreuses optimisations… : initialisation paresseuse, …
• Utilisations connues
– Utilisation courante (systématique…) pour faire apparaître un objet comme
étant local dans les applications distribuées (CORBA, Java RMI)

• Patterns associés
– Adapter, Decorator
– Access Proxy, Remote Proxy, Virtual Proxy, SmartReference

M. Blay-Fornarino & P. Collet 65

 DP Proxy en résumé
• Conséquences
– L’inaccessibilité du sujet est transparente
– Comme le proxy a la même interface que son sujet, il
peuvent être librement interchangeables
– le proxy n’est pas un objet réel mais simplement la réplique
exacte de son sujet

M. Blay-Fornarino & P. Collet 66

 Autres patrons de structure
• Bridge
– Découple l’abstraction de l’implémentation afin de permettre aux deux de varier
indépendamment
– Partager une implémentation entre de multiples objets
– En Java, programmation par deux interfaces
• Flyweight
– Utiliser une technique de partage qui permet la mise en œuvre efficace d’un
grand nombre d’objets de fine granularité
– Distinction entre état intrinsèque et état extrinsèque

P. Collet 67