Dan Garlasu, dgarlasu@yahoo.

com

Bonjours! Vous êtes-vous déjà demandé comment sont conçus les systèmes à l'échelle
d'une grande entreprise ? Avant le début du développement majeur de logiciels, nous
devons choisir une architecture appropriée qui nous fournira les fonctionnalités et les
attributs de qualité souhaités. Par conséquent, nous devons comprendre les différentes
architectures avant de les appliquer à notre conception. Et cette discussion nous
amène déjà au sujet de Modèles de conception (Design Patterns).

1
Ordre du jour
1. Introduction
2. Exemples de modèles de conception
3. Propriétés des modèles de conception

2
 Les modèles sont essentiellement des solutions réutilisables à des problèmes
courants.
 Modèles architecturaux:
◦ Ils définissent une solution pour une variété d'attributs de qualité et envisagent plusieurs
composants dans un système logiciel.
◦ La portée est plus large pour les modèles architecturaux tandis que les modèles de
conception représentent un moyen de structurer les classes pour construire la meilleure
structure interne.
 Modèles de conception:
◦ Fournissent un schéma pour affiner les sous-systèmes ou les composants d'un système
logiciel, ou les relations entre eux;
 Expressions idiomatiques:
◦ Modèles de bas niveau spécifiques à un langage de programmation;
◦ Ils décrivent la manière d’implémenter des aspects particuliers des composants ou les
relations entre eux en utilisant les fonctionnalités du langage donné.

Le Modèle de conception consiste à communiquer des «objets» personnalisés pour

résoudre un problème de lociciel dans un contexte particulier.

Les modèles ont leur origine dans la programmation orientée objet où ils ont
commencé comme des collections d'objets organisés pour résoudre un problème. Il n'y
a pas de relation fondamentale entre les motifs et les objets ; il se trouve qu'ils ont
commencé là. Les modèles peuvent être apparus parce que les objets semblent si
élémentaires, mais les problèmes que nous essayions de résoudre avec eux étaient si
complexes!

3
 Certains problèmes de construction se produisent encore et encore dans un
large éventail d'applications informatiques différentes.
 Nous pouvons concevoir une solution générique à ces problèmes récurrents,
puis essayer de nous adapter aux besoins spécifiques de l'application que
nous construisons actuellement. Ces solutions génériques sont
généralement appelées modèles de conception.
 Ainsi, un modèle de conception est le cœur d'une solution à un problème
dans son contexte. La solution peut être appliquée dans différentes situations
et doit être adaptée pour répondre aux besoins de la situation spécifique.

Au fur et à mesure que nous construisons des systèmes informatiques plus complexes,
nous sommes confrontés à des problèmes de construction plutôt qu'à des problèmes
d'analyse. Ces problèmes de construction sont résolus en concevant des solutions de
programmation dans le contexte de l'application informatique que nous essayons de
construire.

Christopher Alexander, dans le livre « Towns, Buildings, Construction », publié

en 1977, a été le premier a introduire des modèles pour coder les connaissances et
l'expérience dans la conception de bâtiments. Il a déclaré : « Chaque modèle décrit un
problème qui se produit encore et encore dans notre environnement, puis décrit le
cœur de la solution à ce problème de telle manière que vous pouvez utiliser cette
solution plusieurs fois, sans jamais refaire la même chose une deuxiéme fois ».

4
 Les gens utilisent généralement les modèles les plus familiers.
 Chaque modèle a une liste de conséquences associées.
 Les conséquences peuvent potentiellement introduire des
inconvénients.
 Vous devriez prévoir de compenser ces inconvénients.
 Si la conséquence contribue de manière significative au risque,
envisagez de supprimer complètement le motif.

6
 Modèles de configuration matérielle
 Modèles de conception de logiciels
 Les modèles GOF (Gang Of Four)
 Modèles Java EE
 Modèles architecturaux
◦ Modèle d'architecture d'Oracle

7
 Aide à établir des niveaux logiques et
des couches technologiques
 Définit et applique les limites
d'abstraction
◦ Exemple
 L'architecture à plusieurs niveaux des
applications Java EE
 Une couche d'accès aux données abstraite
sous la forme d’enveloppe pour des objets

8
 Les modèles de conception ont été introduits pour la première fois dans la programmation
par le soi-disant «Gang of Four» (Gamma, Helm, Johnson, Vlissides). Ils ont fait référence
aux modèles de conception dans le contexte de la construction de systèmes informatiques
orientés objet.
 Ainsi, les modèles de conception orientés objet peuvent être définis comme des
1. descriptions d’objets et de
2. classes communicantes qui sont
3. personnalisées,
pour résoudre un problème de conception général (orienté objet) dans un contexte particulier.
 Gang of Four ont également déclaré qu'un modèle de conception orienté objet n'est pas:
◦ Un bloc de construction primitif, tel que des listes chaînées ou des tables de hachage qui peuvent
être encodés dans des classes et réutilisés dans un large éventail d'applications;
◦ Une conception complexe et spécifique à un domaine pour une application complète ou un sous-
système.
 Au lieu de cela, un modèle de conception orienté objet décrit simplement une structure de
conception orientée objet, récurrente.

Avez-vous déjà entendu le concept « Gang of Four » ? Il s'agit en fait d'une collection
de modeles de conception créée en 1994 dans le livre "Design Patterns: Elements of
Reusable Object-Oriented Software", qui adopte le surnom de Gang of Four pour être
la création de 4 auteurs. Gardez à l'esprit que ces modèles, comme le nom des détails
du livre original, sont applicables dans le monde de la programmation orientée objet,
qui, bien qu'il soit le paradigme fondamental dans la plupart des applications, ne couvre
pas entièrement le spectre des options.

9
 Ainsi, un modèle de conception orienté objet :
◦ Nomme, résume et identifie les aspectes clé (classes, objets et leurs
relations) d'une structure de conception commune;
◦ Crée une conception orientée objet réutilisable;
◦ Se concentre sur une conception orientée objet particulière en décrivant:
 quand elle s'applique,
 si elle peut être appliquée compte tenu d'autres contraintes de conception, et
 les conséquences et les compromis de son utilisation;
◦ Implémente l'idée de conception dans un langage de programmation
orienté objet.

Dans la suite de ce cours, nous examinerons uniquement les modèles de conception

orientés objet. Ainsi, chaque fois qu’on mentione un modèle de conception, nous nous
référons en fait à un modèle de conception orienté objet.

10
 Chaque modèle a quatre éléments essentiels:
1. Le nom du modèle est un moyen qu’on utilise pour décrire un problème de
conception, ses solutions et ses conséquences en un mot ou deux.
2. Le problème décrit quand appliquer le modèle. Il explique le problème et son contexte.
Parfois, le problème comprend également une liste de conditions qui doivent être
remplies avant qu'il soit logique d'appliquer le modèle.
3. La solution décrit les éléments qui composent la conception, leurs relations,
responsabilités et collaborations, c'est-à-dire une description abstraite d'un problème
de conception et comment un arrangement général d'éléments (classes et objets) le
résout.
4. Les conséquences sont les résultats et les compromis de l'application du modèle. Ils
peuvent également aborder les problèmes de langage de programmation et de mise en
œuvre. Étant donné que la réutilisation est souvent un facteur dans la conception
orientée objet, les conséquences d'un modèle incluent son impact sur la flexibilité,
l'extensibilité ou la portabilité d'un système.

11
 « Gang of Four » a utilisé un format cohérent pour décrire les
modèles. Ils ont développé un cadre qui décrit un modèle de
conception avec :
◦ Nom et classification du modèle (selon le schéma de classification, voir la
section suivante);
◦ Applicabilité du modèle de conception;
◦ Motivation; décrit un scénario typique qui illustre le problème de conception
◦ Applicabilité; quand on peut appliquer le modèle de conception
◦ Structure; une représentation graphique des classes et de leurs collaborations
dans le modèle;
◦ Conséquences du modèle de conception
◦ Implémentation et exemple de code
◦ Modèles associés

Nous appliquerons ce cadre pour montrer quelques exemples de modèles de

conception dans la section suivante.

12
 Les modèles de conception peuvent être classés selon deux
critères :
1. L’Objectif reflète ce que le modèle réalise. Les modèles peuvent avoir
un but créatif, structurel ou comportemental ;
 Les modèles de création concernent le processus de création d'objet;
 Les modèles structurels s’occupent de la composition des classes et des objets;
 Les modèles de comportement caractérisent la manière dont les classes et les
objets interagissent et répartissent la responsabilité.
2. La Portée spécifie si le modèle s'applique principalement aux classes ou
aux objets :
 Les modèles de classe s’occupent des relations entre les classes et leurs sous-
classes. Ces relations sont établies par héritage, elles sont donc statiques.
 Les modèles d'objet s’occupent des relations d'objet, qui peuvent être modifiées
au moment de l'exécution et sont plus dynamiques.

13
 Purpose Design Patterns Scope
 Le tableau suivant montre la Creational Abstract Factory Object

classification des modèles de Builder Object

conception introduits par GoF Factory Method

Prototype
Class
Object
(Gang of Four): Structural
Singleton
Adapter
Object
Class
Bridge Object
Composite Object
Decorator Object
Facade Object
Flyweight Object
Proxy Object
Behavioral Chain of Object
Responsibility

Command Object
Interpreter Class
Iterator Object
Mediator Object
Memento Object
Observer Object
State Object
Strategy Object
Template Class
Method
Visitor Object

Les modèles de conception GoF (Gang of Four) sont divisés en trois catégories :
1. Création : Les modèles de conception qui traitent de la création d'un objet.
2. Structurel : les modèles de conception de cette catégorie traitent de la structure
de classe telle que l'héritage et la composition.
3. Comportemental : Ce type de modèles de conception fournit une solution pour
une meilleure interaction entre les objets, comment fournir un couplage lâche et
une flexibilité pour s'étendre facilement à l'avenir.

14
 Modèles de conception de création
◦ Les modèles de conception de création abstractisent le processus d'instanciation. Ils
aident à rendre un système indépendant de la façon dont ses objets sont :
 établi (créés),
 composé, et
 représentée.
◦ Un modèle de création de classe utilise l'héritage pour faire varier la classe instanciée,
tandis qu'un modèle de création d'objet délègue l'instanciation à un autre objet.
◦ Les modèles de conception de création permettent de configurer un système logiciel
comme un système avec des objets de type « produit » dont la structure et la
fonctionnalité varient considérablement. Une telle configuration peut être :
 statique, c'est-à-dire spécifié au moment de la compilation, ou
 dynamique, c'est-à-dire spécifié au moment de l'exécution.

15
  Intention
◦ Fournir une interface pour créer des familles d'objets liés ou dépendants sans spécifier leurs
classes concrètes
 Motivation
◦ Envisagez une boîte à outils pour permettre aux applications avec des interfaces graphiques de
s'exécuter sur plusieurs plates-formes (Mac/Apple, PC/Windows, Motif/Unix) en utilisant l'apparence
(look-and-feel) de chaque plate-forme. Pour être portable à travers les normes d'aspect et de
convivialité, une application ne doit pas coder en dur ses widgets (gadget logiciel) pour un aspect et
une convivialité particulière. L'instanciation de classes de widgets spécifiques à l'apparence et à la
convivialité dans l'ensemble de l'application rend difficile le changement ultérieur de l'apparence et
de la convivialité

Widget GUI, représente en programmation informatique un élément réutilisable d'une

interface utilisateur graphique. Le widget Web est un widget logiciel pour le Web. Il s'agit
d'une petite application qui peut être installée et exécutée dans une page Web par un
utilisateur final. Ils sont dérivés de l'idée de réutilisation du code.

Avec les widgets, vous pouvez obtenir en un coup d'œil des informations actualisées sur vos
applications préférées. Les widgets vous affichent des informations provenant de vos
applications préférées, telles que Actualités et Bourse. Vous pouvez voir vos widgets dans la
vue Aujourd'hui. Sur votre smartfone, glissez simplement vers la droite sur l'écran d'accueil,
l'écran de verrouillage ou pendant que vous consultez vos notifications.

16
 Nous définissons une classe abstraite WidgetFactory qui déclare une
interface pour chaque type de widget (gadget logiciel) de base.
 Il existe également une classe abstraite pour chaque type de widget, et des
sous-classes concrètes implémentent des widgets pour des normes d'aspect
et de convivialité spécifiques.
 L'interface de WidgetFactory a une opération qui renvoie un nouvel objet
widget pour chaque classe de widget abstrait.

Les clients appellent ces opérations pour obtenir des instances de widget, mais les
clients ne sont pas conscients des classes concrètes qu'ils utilisent. Ainsi, les clients
restent indépendants de l'aspect et de la convivialité dominants. Il existe une sous-
classe concrète de WidgetFactory pour chaque norme d'aspect et de convivialité.
Chaque sous-classe implémente les opérations pour créer le widget approprié pour
l’apparence spécifique (look-and-feel).

17
Applicabilité
On utilise le modèle de conception Abstract Factory si :
◦ Un système doit être indépendant de la manière dont ses produits sont
créés, composés et représentés;
◦ Un système doit être configuré avec l'une des multiples familles de
produits;
◦ Une famille d'objets représentant des produits associés est conçue pour
qu’ils soient utilisées ensemble, et vous devez appliquer cette
contrainte;
◦ Vous souhaitez fournir une bibliothèque de classes de produits et vous
souhaitez révéler uniquement leurs interfaces, pas leurs
implémentations.

18
 La structure de l'usine abstraite:

Les participants à ce modèle de conception sont les suivants :

• AbstractFactory (par exemple WidgetFactory), qui déclare une interface pour les opérations qui
créent des objets produit abstraits;
• ConcreteFactory (par exemple MotifWidgetFactory, MacWidgetFactory, etc.), qui implémente les
opérations pour créer des objets de produit concrets;
• AbstractProduct (par exemple Menu, Window), qui déclare une interface pour un type d'objet
produit;
• ConcreteProduct (par exemple MacWindow, Win95Window, etc.), qui définit un objet produit à
créer par l'usine concrète correspondante en implémentant l'interface AbstractProduct;
• Client, qui utilise uniquement l'interface, déclaré par les classes AbstractFactory et
AbstractProduct.

Habituellement, une seule instance d'une classe ConcreteFactory est créée au moment de
l'exécution. Cette usine concrète crée des objets produits ayant une implémentation particulière. Pour
créer différents objets de produit, les clients doivent utiliser une usine de béton différente.

19
 Le modèle de l’Usine abstraite a les conséquences suivantes :
◦ Isole les classes concrètes en aidant les programmeurs à contrôler les classes
d'objets créées par une application;
◦ Facilite l'échange de familles de produits, car la classe d'une fabrique réelle
n'apparaît qu'une seule fois dans une application, à l'endroit de son
instanciation. Cela facilite le changement de l'usine réelle utilisée par une
application.
◦ Favorise la cohérence entre les produits en obligeant à utiliser des objets de
la même famille d'objets.
◦ La prise en charge de nouveaux types (dans chaque famille) de produits est
difficile, car nous devons non seulement définir de nouveaux objets produit,
mais également étendre toutes les « usines » pour pouvoir créer ces
nouveaux objets produit.

20
abstract class WidgetFactory{
public Window createWindow();
public Menu createMenu();
public Button createButton();
}
class MacWidgetFactory extends WidgetFactory{ class Win95WidgetFactory extends
public Window createWindow() WidgetFactory{
{ code to create a mac window } public Window createWindow()
{ code to create a Win95 window }
public Menu createMenu()
{ code to create a mac Menu } public Menu createMenu()
{ code to create a Win95 Menu }
public Button createButton()
{ code to create a mac button } public Button createButton()
} { code to create a Win95 button }
}

Voici une implémentation simple en Java de l'exemple ci-dessus.

21
  Voici le code d'un client. Nous devons juste nous assurer que
l'application crée un objet ConcreteFactory approprié.

public void installDisneyMenu(WidgetFactory myFactory){

Menu disney = myFactory.createMenu();
disney.addItem( "Disney World" );
disney.addItem( "Donald Duck" );
disney.addItem( "Mickey Mouse" );
disney.addGrayBar( );
disney.addItem( "Minnie Mouse" );
disney.addItem( "Pluto" );
etc.

Modèles associés
Les classes AbstractFactory sont souvent implémentées avec des méthodes de
fabrique (modèle Factory Method), mais elles peuvent également être implémentées à
l'aide du modèle de conception Prototype. Une usine réelle est souvent un singleton
(modèle de conception Singleton).

Le modèle de conception Singleton garantit qu'une classe n'a qu'une seule instance et
lui fournit un point d'accès global. Une bonne utilisation de ce modèle est par exemple
lors de la création d'une connexion à une base de données ; nous voulons nous
assurer que la connexion n'est pas créée plusieurs fois mais que la même instance est
réutilisée plusieurs fois.

22
 Quand utiliseriez-vous le modèle de conception Singleton dans votre
projet Java ?
a) Pour garantir qu'une classe n'a qu'une seule instance et lui fournir un point
d'accès global.
b) Pour assurer que la connexion n'est pas créée plusieurs fois mais que la même
instance est réutilisée plusieurs fois.
c) Pour déclarer une interface pour les opérations qui créent des objets produit
abstraits

Response: a, b.

23
Pouvez-vous donner un exemple d'implémentation du
modèle de conception Abstract Factory en Java ?
a) WidgetFactory
b) WidgetOperations
c) ImageObserver

24
 Les modèles structurels concernent la façon dont les classes et les objets
sont composés pour former des structures plus grandes.
 Les modèles de classes structurelles utilisent l'héritage pour composer des
interfaces ou des implémentations.
◦ Par exemple, l'héritage multiple peut être considéré comme une sorte de modèle de
conception structurelle, car il utilise l'héritage pour mélanger deux ou plusieurs classes en
une nouvelle.
 Plutôt que de composer des interfaces ou des implémentations, les modèles
d'objets structurels décrivent des façons de composer des objets pour
réaliser de nouvelles fonctionnalités.
 La flexibilité supplémentaire de la composition des objets provient de la
possibilité de modifier la composition au moment de l'exécution, ce qui est
impossible avec la composition de classe statique.

25
 Intention
◦ Le modèle de conception Composite, compose des objets dans des
structures arborescentes pour représenter des hiérarchies partie-entier. Le
modèle composite permet aux clients de traiter des objets individuels et des
compositions d'objets de manière uniforme.
 Motivation
◦ Abstract Windows Toolkits (AWT) permet à l'utilisateur de créer des interfaces
utilisateur graphiques complexes. L'utilisateur peut regrouper un certain
nombre d'éléments d'interface utilisateur simples (tels que des boutons radio,
des éléments de menu, etc.) pour former des composants plus grands (tels
qu'un groupe de boutons radio, un menu, etc.). Une implémentation simple
d'un AWT pourrait implémenter des classes pour les primitives d'interface
utilisateur et d'autres classes qui agissent comme des conteneurs pour ces
primitives.

Le modèle composite est utilisé lorsqu’on doit créer une hiérarchie partitionnée. Il
compose zéro ou plusieurs objets similaires afin qu'ils puissent être manipulés comme
un seul objet. Un exemple parfait de ce modèle est une structure arborescente, où des
nœuds ou des objets feuille sont utilisés pour créer des résultats plus complexes.

26
 Mais il y a un problème avec cette approche :
◦ Le code qui utilise ces classes doit traiter différemment les objets primitifs et
conteneurs, même si la plupart du temps l'utilisateur les traite de manière
identique. La nécessité de distinguer ces objets, complique inutilement
l'application.
◦ Le modèle Composite décrit comment utiliser la composition récursive afin
que les clients n'aient pas à faire cette distinction.

Boîte à outils de fenêtre abstraite typique

27
 La clé du modèle Composite est une classe abstraite qui représente
à la fois les primitives et leurs conteneurs
 Pour l'Abstract Window Toolkit (AWT), cette classe est la classe
Component.

Application du modèle composite pour un AWT

La classe Component déclare des opérations telles que Dessiner, Afficher, etc. qui
sont spécifiques à tous les éléments de l'interface utilisateur graphique. Il déclare
également les opérations partagées par tous les objets composites, telles que les
opérations d'accès et de gestion de ses enfants.

28
 Par exemple, le standard
Java AWT utilise le
modèle Composite

29
Applicabilité
 Utilisez le motif composite lorsque :
◦ Vous voulez représenter des hiérarchies partie/entièr de touts objets
◦ Vous voulez que les clients puissent ignorer la différence entre les
compositions d'objets et les objets individuels. Les clients traiteront
tous les objets de la structure composite de manière uniforme

30
 Les participants du modèle Composite sont les suivants :
◦ Composant;
◦ Feuille – engl: Leaf (bouton, menu, etc.);
◦ Composite (WidgetContainer);
◦ Client.

Participants du modèle composite:

• Composant (Component), qui déclare l'interface pour les objets de la
composition.
• Feuille (bouton, menu, etc.), qui représente les objets feuille dans la composition.
• Composite (WidgetContainer), qui définit le comportement des composants ayant
des enfants.
• Client, qui manipule les objets de la composition via l'interface de composant
uniforme.

31
 Le pattern Composite a les conséquences suivantes :
1. Rend le client simple, puisque les clients traitent la structure composite et
les objets individuels de manière uniforme.
2. Facilite l'ajout de nouveaux types de composants.
3. Rend difficile la restriction des composants d'un composite.
 Parfois, vous voulez qu'un composite n'ait que certains composants. Cependant,
avec le modèle composite, vous devez implémenter des contrôles d'exécution pour
garantir cette restriction.

32
abstract class Component{
private Component parent;
abstract public void update();
abstract public void add();
public void setParent(Component par){
parent = par;
}
}
class WidgetContainer extends Component{
Component[] myComponents;

public void update(){

if ( myComponents != null )
{
for ( int k = 0; k < myComponents.length(); k++ )
{
myComponents[k].update();
}
}
}

33
 class Button extends Component{
public void update(){
etc.
}
etc.
}

Modèles associés
 Le motif Décorator est souvent utilisé avec Composite. Lorsque les modèles
Décorater et Composit sont utilisés ensemble, ils ont généralement une classe parent
commune. Le modèle Décorator doit donc prendre en charge l'interface Component
avec des opérations telles que Add, Remove et GetChild.
 Le modèle Itérator peut être utilisé pour parcourir les composites.

 Le modèle Visitor localise les opérations et le comportement qui seraient autrement

répartis entre les classes Composite et Leaf.

Le modèle Décorateur ajoute/supprime dynamiquement le comportement dans une

méthode existante d'un objet. La fonctionnalité d'un objet est modifiée au moment de
l'exécution. Nous pouvons voir que ce modèle est une pièce fondamentale sur des
frameworks tels que Angular ou NestJS.

34
 Quel est un bon scénario pour utiliser le modèle de conception
Composit, en Java ?
a) décrire comment un groupe d'objets peut coopérer pour
effectuer une tâche qu'aucun objet ne peut effectuer seul.
b) Vous voulez que les clients puissent ignorer la différence
entre les compositions d'objets et les objets individuels.
c) nous avons besoin d'écrire un programme qui calcule la
somme de tous les composants d'un objet List donné.

Response: b.

35
 Les modèles de comportement concernent les algorithmes et l'attribution des
responsabilités entre les objets. Ils décrivent non seulement des modèles
d'objets ou de classes, mais également les modèles de communication entre
eux.
◦ Ces modèles caractérisent un flux de contrôle complexe, difficile à suivre au moment de
l'exécution. Ils détournent votre attention du flux de contrôle pour vous permettre de vous
concentrer uniquement sur la manière dont les objets sont interconnectés.
 Le modèle comportemental de classe utilise l'héritage pour distribuer le
comportement entre les classes.
 Le modèle comportemental de l’objet utilise la composition d'objets plutôt
que l'héritage.

Exemples:
un modèle comportemental d'objet peut décrire
comment un groupe d'objets peut coopérer pour
effectuer une tâche qu'aucun objet ne peut effectuer
seul. Un exemple typique est le modèle Observer du
langage Smalltalk (paradigme Modèle/Vue/Contrôleur).

36
 Intention
 Le modèle de conception Visitor représente une opération à effectuer
sur les éléments d'une structure d'objet. Il permet de définir de nouvelles
opérations sans changer les classes des éléments sur lesquels il opère.

Motivation
 Considérez l'implémentation suivante de listes d'entiers écrites en Java :
interface List {}

class Nil implements List {}

class Cons implements List {

int head;
List tail;
}

Supposons que nous avons besoin d'écrire un programme qui calcule la somme de
tous les composants d'un objet List donné (présenté au diapo). La première
implémentation évidente serait de vérifier pour chaque objet son type exact (en Java,
nous pouvons le faire avec l'opérateur instanceof). Ensuite, si l'objet est de type Cons-
object, les champs sont accessibles via la conversion de type (type casting) et la
boucle est répétée, sinon, si le type est Nil-object, on passe simplement à l'objet
suivant.
L'avantage de ce code est qu'il peut être écrit sans toucher aux classes Nil et Cons.
Cependant, l'inconvénient est que le code utilise constamment la conversion de type et
instanceof pour déterminer quelle classe d'objets il considère.

37
 Une autre implémentation possible consiste à définir une méthode abstraite
dans l'interface List, par ex. méthode sum. Ensuite, toutes les sous-classes,
c'est-à-dire Cons et Nil implémentent la méthode sum pour fournir la somme
exacte de ses éléments. Ainsi, la classe Nil renvoie 0, tandis que la classe
Cons parcourt ses objets.
 L'avantage de ce code est que la conversion de type et les opérations
instanceof ont disparu.
 L'inconvénient est que chaque fois que nous voulons effectuer une nouvelle
opération sur les objets List, de nouvelles méthodes dédiées doivent être
écrites pour toutes les classes et les classes doivent être recompilées.

38
Enfin, prenons un modèle de conception comportementale pour Visitor.
 Nous pouvons l’implémenter en regroupant les opérations liées de
chaque classe dans un objet séparé, appelé Visitor, et en le
transmettant aux éléments de l'objet List. Lorsqu'un élément de la
Liste « accepte » Visitor, il envoie une requête au Visitor, qui encode
la classe de l'élément. Il inclut également cet élément comme
argument. Visitor exécutera l'opération pour cet élément et calculera
la somme correcte pour cet élément.
 L'avantage est que l'on peut écrire du code qui manipule des objets de
classes existantes sans recompiler ces classes.
 Le prix est que tous les objets doivent avoir une méthode « accept »

39
 Utilisez le modèle Visitor lorsque :
◦ Une structure d'objet contient de nombreuses classes d'objets avec
des interfaces différentes, et vous souhaitez effectuer des opérations
sur ces objets qui dépendent de leurs classes concrètes.
◦ De nombreuses opérations distinctes et non liées doivent être
effectuées sur des objets dans une structure d'objet.
◦ Les classes définissant la structure de l'objet changent rarement,
mais vous souhaitez souvent définir de nouvelles opérations sur la
structure

40
Les participants du modèle Visiteur sont les suivants :
Visitor (ListVisitor), qui déclare une opération Visit pour chaque classe de
ConcreteElement dans la structure de l'objet.
ConcreteVisitor (SumVisitor), qui implémente chaque opération déclarée par
Visitor.
Element (ListElement), qui définit une opération Accept qui prend un visiteur
comme argument.
ConcreteElement (Cons, Nil), qui implémente une opération Accept qui prend un
visiteur comme argument.
ObjectStructure (List), qui peut énumérer ses éléments.
Ainsi, lorsqu'un élément est visité, il appelle l'opération Visiteur qui correspond à
sa classe. L'élément se fournit soi-même en argument à cette opération, pour
permettre au visiteur d'accéder à son état, si nécessaire.

41
 Les conséquences du modèle Visitor sont les suivantes :
◦ Le visiteur facilite l'ajout de nouvelles opérations.
◦ Un visiteur regroupe les opérations liées et en même temps sépare les
opérations qui ne sont pas liées.
◦ L'ajout d'une nouvelle classe ConcreteElement est difficile, car chaque
nouveau ConcreteElement donne lieu à une nouvelle opération abstraite sur
Visitor et à l'implémentation correspondante dans chaque classe
ConcreteVisitor.
◦ La visite est possible à travers les hiérarchies de classe.
◦ Visitor casse parfois l'encapsulation d'une classe ConcreteElement, car nous
devons fournir des opérations publiques qui permettent à Visitor de vérifier
l'état interne de ConcreteElement.

42
 interface List{
void accept(Visitor v);
}
class Nil implements List{
public void accept(Visitor v)
{
v.visitNil(this);
}
}
Modèles associés class Cons implements List{
Les modèles liés au modèle Visitor sont le modèle int head;
Composite car Visiteur est souvent utilisé pour List tail;
appliquer une opération sur une structure d'objet public void accept(Visitor v){
v.visitCons(this);
définie par le modèle Composite }
}
interface Visitor{
void visitNil(Nil x);
void visitCons(Cons x);
}
class SumVisitor implements Visitor{
int sum = 0;
public void visitNil(Nil x) {}
public void visitCons(Cons x){
sum = sum + x.head;
x.tail.accept(this);
}
}

43
 Qu'est-ce que le modèle de conception Observer ?
a) Il peut décrire comment un groupe d'objets peut coopérer
pour effectuer une tâche qu'aucun objet ne peut effectuer
seul
b) Il peut garantir qu'une classe n'a qu'une seule instance et
lui fournir un point d'accès global
c) il fournit une interface simplifiée d'encapsulation pour une
grande partie du code

Response: a.

44
Quelles sont les utilisations du modele de conception Visitor?
a) Une structure d'objet contient de nombreuses classes d'objets avec
des interfaces différentes, et vous souhaitez effectuer des
opérations sur ces objets qui dépendent de leurs classes
concrètes.
b) De nombreuses opérations distinctes et non liées doivent être
effectuées sur des objets dans une structure d'objet.
c) Les classes définissant la structure de l'objet changent rarement,
mais vous souhaitez souvent définir de nouvelles opérations sur la
structure

45
 3.1 Résoudre les problèmes de conception avec les modèles de
conception
Trouver des objets appropriés
 Les programmes orientés objet sont constitués d'objets. La partie difficile
de la conception orientée objet consiste à décomposer un système en
objets. Les modèles de conception peuvent aider dans ce processus en
identifiant les abstractions moins évidentes et les objets qui les capturent.
◦ Par exemple, les objets qui représentent un processus ou un algorithme n'existent pas
dans la nature, mais ils peuvent être cruciaux dans une conception flexible. Le modèle
Strategy décrit comment implémenter des familles d'algorithmes pour résoudre un
problème particulier. Ces algorithmes peuvent être échangés au moment de
l'exécution, car ils sont maintenant des objets et sont sujets au polymorphisme par
exemple.

Le modele Strategy permet la sélection d’un algorithme particulier d'une famille

d'algorithmes à la volée lors de l'exécution, sans que le client consommateur ne s'en
rende compte. Un exemple de ce modèle e l’utiliser dans une situation d'expédition où
nous pouvons livrer un colis en 3 stratégies différentes : air, mer ou terre.

46
 Habituellement, les objets varient en :
◦ Taille;
◦ Numéro.
 Les objets peuvent représenter tout jusqu'au matériel ou jusqu'à des
applications entières.
 Les modèles de conception peuvent aider à déterminer la granularité
appropriée des objets.
◦ Par exemple, le modèle Facade décrit comment représenter des sous-systèmes complets
en tant qu'objets, et le modèle Flyweight décrit comment prendre en charge un grand
nombre d'objets aux granularités les plus fines.
 Un certain nombre d'autres modèles, tels que Composite, décrivent
comment décomposer un objet en objets plus petits.

Façade fournit une interface simplifiée d'encapsulation pour une grande partie du code. Il est
souvent présent dans les systèmes construits autour d'une architecture multicouche. Un
exemple peut être comment 3 sous-systèmes sont utilisés pour valider une demande
d'assurance.

Flyweight aide à mettre en cache et à réutiliser les instances d'objets. Il est couramment
utilisé avec des objets immuables. Cela réduit le coût de création et de manipulation d'un
grand nombre d'objets similaires. On peur considere l'exemple, FlyweightFactory qui gère un
pool d'objets Flyweight. L'usine vérifiera s'il en existe déjà un; sinon, un nouveau sera créé et
stocké pour référence future. Plusieurs voitures différentes sont ajoutées à une
CarsCollection. À la fin, nous avons une liste de 7 objets Cars qui ne partagent que 2
Flyweights. Avec de grands ensembles de données, les économies de mémoire peuvent être
importantes.

Composite est utilisé lorsque nous devons créer une hiérarchie partitionnée. Il compose zéro
ou plusieurs objets similaires afin qu'ils puissent être manipulés comme un seul objet. Un
exemple parfait de ce modèle est une structure arborescente, où des nœuds ou des objets
feuille sont utilisés pour créer des résultats plus complexes.

47
 Les modèles de conception aident les programmeurs à définir les
interfaces en identifiant leurs éléments clés et le type de données
qui sont envoyées via une interface.
◦ Un modèle de conception peut également indiquer ce qu'il ne faut pas mettre
dans l'interface.
◦ Par exemple, le modèle Memento décrit comment encapsuler et enregistrer
l'état interne d'un objet afin que l'objet puisse être restauré ultérieurement
dans cet état. Le modèle stipule que les objets Memento doivent définir deux
interfaces :
 Un accès restreint qui permet aux clients de conserver et de copier des souvenirs
 Un privilégié que seuls les objets d'origine peuvent utiliser pour stocker et
récupérer l'état dans Mémento.

Memento offre la possibilité de restaurer un objet à son état précédent (annuler une
action sur l’objet). Un exemple peut être un gestionnaire de contacts qui offre la
possibilité de restaurer l'identité d'origine d'une personne grâce à des méthodes
d'hydratation/déshydratation.

48
 Concevoir un système qui est robuste aux changements est une
tâche plutôt difficile à faire. Cependant, une conception qui ne prend
pas en compte les modifications risque d'être remaniée à l'avenir.
Les modèles de conception peuvent garantir qu'un système peut
changer de manière spécifique.
 Chaque modèle de conception permet à certains aspects de la
structure du système de varier indépendamment d'autres aspects,
rendant ainsi un système plus robuste à un type particulier de
changement

49
 La création d'un objet en spécifiant une classe engage explicitement une
implémentation particulière au lieu d'une interface particulière. Cela signifie
que si nous voulons à l'avenir changer l'objet que nous utilisons, nous
devons également implémenter à nouveau le code client. D'autre part,
l'utilisation des modèles de conception, tels que le modèle Abstract Factory,
vous permet d'éviter ce problème.
 La dépendance de la plate-forme matérielle et logicielle. Les clients qui
savent comment un objet est représenté, stocké, localisé ou implémenté
peuvent avoir besoin de modifications lorsque l'objet change. La possibilité
de masquer ces informations aux clients empêche les modifications de se
répercuter en cascade.
 Un exemple est à nouveau Abstract Factory, utilisé pour créer différents
composants d'aspect et de convivialité sur différents systèmes d'exploitation.

50
Quelles sont les utilisations populaires du motif de conception
Façade ?
a) Le modèle Façade décrit comment représenter des sous-
systèmes complets en tant qu'objets
b) Il est souvent présent dans les systèmes construits autour
d'une architecture multicouche.
c) Décrit comment prendre en charge un grand nombre
d'objets aux granularités les plus fines

51
 Vocabulaire de conception commun
◦ Les modèles de conception devraient fournir un vocabulaire commun
aux concepteurs.
◦ Les modèles de conception rendent un système moins complexe, car
nous pouvons parler en termes de modèles de conception différents
plutôt qu'en termes de langages de programmation.
 Une aide à la documentation
◦ Décrire un système en appliquant un vocabulaire de conception
commun facilite la compréhension de ce système.

Vocabulaire de conception commun

• Les informaticiens et les programmeurs créent des noms pour les algorithmes et
les structures de données. De même, les modèles de conception devraient fournir
un vocabulaire commun aux concepteurs. Un tel vocabulaire peut être utilisé pour
communiquer, documenter et explorer les décisions de conception.
• Les modèles de conception rendent un système moins complexe, car nous
pouvons parler en termes de modèles de conception différents plutôt qu'en termes
de langages de programmation.
Une aide à la documentation
• Avoir un vocabulaire aussi commun signifie que vous n'avez pas à décrire
l'ensemble du modèle de conception ; les programmeurs peuvent simplement le
nommer et s'attendre à ce que le lecteur sache déjà ce que signifie un modèle
spécifique. Par conséquent, écrire la documentation peut devenir beaucoup plus
intéressant et plus facile

52
 "Design Patterns: Elements of Reusable Object-Oriented Software“, by Gamma,
Helm, Johnson, Vlissides, 1994.
 Modern-Day Architecture Design Patterns for Software Professionals by Tanmay
Deshpande
 10 Common Software Architectural Patterns in a nutshell by Vijini Mallawaarachchi
 7 Architecture Design Patterns — You wish you knew before interview,
7 Architecture Design Patterns — You wish you knew before interview | by Toxic Dev | Apr, 2023 | Web3 News & Blogging Website — 2023 (medium.com)

 Design patterns every data engineer should know,

Design patterns every data engineer should know | by Raj Samuel | Medium
 Gang of Four: Fundamental Design Patterns,
Gang of Four: Fundamental Design Patterns | by Williams O | Medium

53