Patrons de conception

Enseignante : Mme Houda ANOUN

houda.anoun@gmail.com
 Modalités d’évaluation
 Travail personnel :
◦ Implémentation en Java d’un exemple concret
qui illustre chaque patron de conception
◦ Mini-projet : une petite application (idéalement
un jeu ☺) extensible à concevoir et à réaliser
en appliquant un certain nombre de patrons de
conception (au moins 3)

 Quiz (à l’improviste)
 Examen final
Plan du cours

 Introduction générale
 Patrons de création
 Patrons de structure
 Patrons de comportement
 Motivation
 "Concevoir un logiciel orienté-objet est difficile,
et concevoir un logiciel orienté-objet
réutilisable est encore plus difficile." - Erich
Gamma

 Les concepteurs expérimentés réutilisent

des solutions qui ont fonctionné dans le
passé

 Les systèmes orientés-objet bien structurés

suivent des patrons récurrents pour les
classes et objets
 Qu’est ce qu’un patron de conception?
Patron de conception = design pattern
 Il traite un problème de conception récurrent
 Il apporte une solution générale :
◦ Description de l'organisation de classes et
d'instances en interaction
 Solution générique de conception :
◦ élégante et réutilisable
◦ testée et validée dans l'industrie logicielle
◦ vise un gain en terme de génie logiciel
◦ indépendante du contexte
 Devenir un champion aux
échecs
 Apprendre à développer un bon logiciel est similaire à
apprendre à bien jouer aux échecs.
 D'abord apprendre les règles
◦ Par exemple le nom des pièces, les mouvements permis, la
géométrie de l'échiquier, etc.
 Puis apprendre les principes
◦ Par exemple la valeur relative de certaines pièces, la
valeur stratégique des emplacements centraux, etc.
 Cependant, pour devenir un champion aux échecs, il
faut étudier le jeu d'autres champions
◦ Ces jeux contiennent des patrons qui doivent être
compris, mémorisés, puis appliqués de manière répétée.
 Devenir un champion du
développement logiciel
 D'abord apprendre les règles
◦ c.a.d. les algorithmes, les structures de données, UML, les
langages de programmation, etc.

 Puis apprendre les principes

◦ Par exemple la programmation structurée, la conception
UML, la programmation orientée-objet, la programmation
générique, etc.

 Mais pour devenir un champion de la conception

logicielle, il est important d'étudier la conception
d'autres champions
◦ Ces conceptions contiennent des patrons qui doivent être
compris, mémorisés, et appliqués de manière répétée.
 Gang des 4 : Patrons de conception
 Le premier livre sur les patrons de conceptions (1995) :
‘Design Patterns’ par Erich Gamma, Richard Helm, Ralph Johnson,
et John Vlissides’ : connus comme le Gang des 4 (‘Gang of Four’)
 Catalogue de 23 patrons de conception
 Classification du GoF pour les
patrons de conception
 3 types de patrons de conception :
1. Patrons de création
 Concernent le processus de la création d'objets
 Les patrons de création aident à créer des objets pour vous, au lieu
d’avoir à instancier les objets directement.

2. Patrons de structure
 Concernent la composition de classes et d'objets
 Les patrons de structure aident à composer des groupes d’objets en des
structures plus larges

3. Patrons de comportement
 Concernent l'interaction des classes et des objets
 Les patrons de comportement aident à définir la communication entre
les objets du système et distribuer les responsabilités
 Template des patrons de conception
 Objectif
◦ Description de son utilité
 Problème / Motivation
◦ Quand appliquer le patron de conception
◦ Un exemple illustrant quand le patron serait utile
 Solution proposée
◦ Eléments impliqués & leurs relations
◦ Schémas conceptuels (e.g. diagrammes UML)
 Conséquences
◦ Avantages et inconvénients du patron
 Implémentation
◦ Implémenter un exemple en Java (votre mission!)
 Patrons liés
◦ Autres patrons qui sont liés de manière proche à ce patron
 Patrons de création
 (Méthode) Fabrique / Factory Method :
◦ Déléguer la création d'un objet aux classes dérivées
 Fabrique abstraite / Abstract Factory
◦ Créer une famille d'objets cohérents
 Monteur / Builder
◦ Construire des objets complexes de manière
incrémentale
 Prototype / Prototype
◦ Créer un objet par clonage d'une instance modèle
 Singleton / Singleton
◦ Garantir une seule instance pour une classe
 Fabrique (1)
 Objectif :
Déléguer la création d'un objet aux classes dérivées
 Problème :
◦ Création d’une commande adéquate pour chaque
catégorie de clients
◦ Deux catégories de clients :
 ClientComptant : paie au comptant les articles commandés
 création d’une instance de CommandeComptant
 ClientCrédit : utilise un crédit
 création d’une instance de CommandeCrédit
 Fabrique (2)
• Solution proposée :
 Fabrique (3)
• Structure générique :
 Fabrique (4)
 Commentaires :
◦ Méthode «créerCommande( ) : Commande » est une
méthode «fabrique» (nommée aussi «constructeur virtuel»)

 Conséquences :
◦ Le processus de création peut être changé par héritage
◦ Le client demande au créateur de lui fournir une instance
◦ Le client ne connaît que l'interface de l'objet (e.g. Commande)
◦ Seul le créateur concret connaît la classe réelle de l'objet

public static void main(String args[]) {

Client c = new ClientComptant( );
Commande cm = c.créeCommande(1000);
…}
 Fabrique (5)

 Relations avec d'autres patrons

◦ Fabrique abstraite : utilise la fabrique dans son
implémentation
◦ Méthode patron : la classe abstraite « Creator »
peut contenir des méthodes patron (anOperation)
 Fabrique abstraite (1)
 Objectif :
Créer des familles d'objets cohérents sans avoir
à spécifier leurs classes concrètes.
 Problème :
◦ Le système de vente de véhicules gère deux
familles de véhicules : à essence et électriques.
◦ Pour chaque produit (Scooter, Automobile) nous
disposons d’une classe abstraite et de deux sous-
classes concrètes décrivant les deux versions du
produit (essence/électrique)
◦ Comment faciliter la création de produits de la
même famille?
 Fabrique abstraite (2)
si (famille = essence)
- stp fabrique moi un
scooter (bleu, …)

-stp fabrique moi Fabrique des

véhicules essence
une automobile (gris, Mini, …)
 Fabrique abstraite (3)
• Solution proposée
 Fabrique abstraite (4)
• Structure générique :
 Fabrique abstraite (5)
 Conséquences
◦ Le client demande à la fabrique de lui fournir des
instances
◦ Le client ne connaît que les interfaces des objets
◦ Seule la fabrique connaît les classes réelles des objets
◦ Echange de famille de produits très facile : remplacer
la fabrique concrète par une autre
◦ Ajout d’un nouveau produit difficile!
 Relations avec d'autres patrons
◦ Singleton : Souvent, une seule instance de chaque
fabrique
◦ (Méthode) Fabrique : Une méthode fabrique par
type de produit
 Monteur (1)
 Objectif :
◦ Séparer la construction d'un objet complexe de sa
représentation
◦ Même processus de construction mais représentations
différentes
 Problème :
◦ Plusieurs représentations de pizza :
 (pizza FruitsMer/piquante/4 fromages …)
◦ Processus de construction identique :
 Nouvelle pizza
 Monter pate (pate fine/épaisse… )
 Monter sauce (douce/piquante )
 Monter garnitures(fruits mer/charcuterie …)
 Monteur (2)
• Solution proposée
 Monteur (3)
• Structure générique :
 Monteur (4)
 Diagramme de séquence
 Monteur (5)
 Conséquences :
◦ Un «directeur» construit une structure complexe
◦ Il délègue la création des parties à un «monteur»
◦ Isolation de la construction et de la représentation :
 Le processus de création des parties est masqué
 Le processus d'assemblage des parties est masqué
◦ Echange de représentation d'une structure
complexe facile : remplacer le monteur concret par
un autre
 Relations avec d'autres patrons
◦ Fabrique abstraite : construction d'une famille de
produits
◦ Monteur : construction pas à pas d'un produit
complexe
 Prototype (1)
 Objectif :
Créer un objet par clonage d'une instance modèle
 Problème
◦ Palette de dessin
◦ Mauvaise solution :
Création différente
au sein de chaque bouton
new Maison(Color.RED,
Color.WHITE, 16, 32, 16)

new Arbre(Color.GREEN,
Color.BROWN, 8, 32, 8)
 Prototype (2)
• Solution proposée
Chaque bouton contient un prototype à cloner

Pour simplifier, on considère

une palette de dessin de
cercles/rectangles (au lieu
des arbres/maisons…)
 Prototype (3)
• Structure générique :
 Prototype (4)
 Conséquences
◦ Le client utilise la méthode de clonage de l’objet
prototype pour obtenir une copie
◦ Le client n’a pas besoin de connaitre le type concret
de l’objet (il est déterminé par celui de l'instance
modèle)
 Relations avec d'autres patrons
◦ Fabrique abstraite : peut utiliser des prototypes
pour créer les objets
 En Java
◦ Tous les objets appartiennent à la classe «Object»
◦ Cette classe fournit une méthode «clone»
 Singleton (1)
 Objectif :
Restreindre l’instanciation d’une classe à un
seul objet
 Solution proposée

31
 Singleton (2)
 Structure générique

 Création d'un objet :

◦ Interdit: new Singleton(...)
◦ Autorisé: Singleton.getInstance()
 Singleton (3)
 Conséquences :
◦ L’instanciation explicite par le constructeur est
interdite (tous les constructeurs sont privés)
◦ La méthode de classe publique getInstance
construit une instance de la classe la première fois
qu’elle est appelée (elle stocke sa référence dans
un attribut de classe) et renvoie cette même
référence lors des invocations suivantes.
 Relations avec d'autres patrons
◦ Fabrique abstraite / Monteur / Prototype : ils
peuvent utiliser le singleton dans leur
implémentation
 Singleton (4)
 Précautions
◦ si multi-threadé:

 synchroniser getInstance()
class Singleton {
public static synchronized Singleton
getInstance() {……}

 ou initialisation statique (au chargement)

class Singleton {
private static instance=new Singleton();
public static Singleton getInstance()
{return instance;}}
 Quiz 1
 Quel patron de conception est représenté
par le diagramme de classes suivant?
 Quiz 2
On souhaite créer une application d’initiation à
l’algorithmique qui peut s’adapter à des publics
différents (enfants, lycéens etc)

Exemple :
Pour les lycéens, le bouton ‘effacer tout’
prendra une allure différente :

Effacer tout

Quel patron de conception peut-on utiliser pour

ce besoin? Proposer un schéma UML adéquat
 Patrons de structure (1)
 Adaptateur / Adapter
◦ Adapter l'interface d'une classe à ses besoins
 Pont / Bridge
◦ Découpler l'interface d'un composant de son
implémentation
 Composite / Composite
◦ Composer des objets sous forme arborescente
 Décorateur / Decorator
◦ Ajouter dynamiquement des fonctionnalités à un
objet
 Patrons de structure (2)

 Façade / Facade
◦ Fournir une interface unifiée à l’ensemble des
interfaces des sous-systèmes
 Poids-mouche / Flyweight
◦ Partager des instances pour éviter un nombre
trop important
 Proxy / Proxy
◦ Fournir un substitut pour accéder à un objet
 Adaptateur (1)
 Objectif :
Convertir l’interface d’une classe existante en
une autre compatible avec l’application cliente
 Problème
◦ Utiliser les fonctionnalités d’une bibliothèque
tierce mais l’interface n’est pas adaptée
 Adaptateur(2)
• Solution proposée

Un serveur web du
système de vente de
véhicules crée et gère
des documents destinés
aux clients (html ou pdf).
Les documents Pdf sont
complexes à gérer. Un
composant du marché
ComposantPdf a été
choisi mais son interface
est incompatible avec
l’interface Document!
 Adaptateur (3)
• Structure générique :
 Adaptateur (4)

 Conséquences
◦ Appelé aussi « wrapper »
◦ Permettre le dialogue entre classes incompatibles
◦ Indications d'utilisation :
• quand on veut utiliser une classe existante mais dont
l'interface ne coïncide pas avec celle attendue
 nom des opérations
 nombre de paramètres, types …
◦ Solution : Un objet de la classe adaptée est agrégé
dans l'adaptateur
 Pont (1)
 Objectif :
Séparer l'interface d'un composant de son
implémentation
 Problème :
Un switch (composant)
admet deux
fonctionnalités on( ) et
off( ).
Il existe plusieurs
catégories de switchs
(interrupteur,
télécommande) qui
interagissent avec
différents appareils
(télévision, aspirateur…)
 Pont (2)
• Solution proposée
 Pont (3)
 Structure générique
 Pont (4)
 Conséquences :
◦ Augmentation de l'extensibilité : deux hiérarchies
séparées: Composant et Implémenteur
◦ Chaque composant agrège une implémentation à
laquelle il délègue les appels aux méthodes
◦ Masquer totalement l'implémentation : plus
d'attributs déclarés dans le composant
 Relations avec d'autres patrons
◦ Pont s'utilise en phase de conception, alors que
Adaptateur s'applique à des classes existantes
pour les connecter à posteriori
 Composite (1)
 Objectif :
Composer des objets en structures arborescentes
pour représenter des hiérarchies récursives
composant/composé
 Problème

Un répertoire est composé de

fichiers et sous-répertoires
 Composite (2)
• Solution proposée
 Composite (3)
 Utilisation : Interfaces graphiques (java.awt)
 Composite (4)
 Structure générique
 Composite (5)
 Conséquences :
◦ L’ajout de nouveaux types de composants est facile
◦ Simplification des applications clientes qui n'ont pas à
se soucier du statut du composant (feuille ou
composite)
 pour cela il est conseillé de maximiser l'interface de
Composant, même si certaines opérations ne feront rien dans
Feuille (ex. ajouter/retirer)
 Relations avec d'autres patrons
◦ Itérateur : utilisé pour parcourir les composants
◦ Visiteur : utilisé pour appliquer une opération à tous
les composants
 Décorateur (1)
 Objectif :
◦ Ajouter dynamiquement des fonctionnalités à un objet
◦ Alternative à l'héritage pour étendre les fonctionnalités
 Problème :

On veut rajouter
des propriétés à un
composant d’IHM
comme une
bordure, une barre
de défilement …
 Décorateur (2)
• Solution proposée
 Décorateur (3)
 Utilisation : Stream en Java
 Décorateur (4)
 Structure générique
 Décorateur (5)
 Conséquences :
◦ Une alternative à l'héritage qui pourrait conduire à une
hiérarchie lourde :
 Exemple de la zone de texte : 3 héritages sont nécessaires
(bordure, défilement, les deux)
 Extension de la zone de texte : Extension des 3 classes
◦ Ajouter dynamiquement des fonctionnalités à un objet
sans affecter les autres instances de la même classe
◦ Mais comportement inattendu :
new DecorateurBordure(new DecorateurFond(zt)) ≠
new DecorateurFond(new DecorateurBordure(zt)) ?
 Relations avec d'autres patrons
◦ Composite : utilisation «dégénérée» (1 seul enfant) du
patron composite
 Façade (1)
 Objectif :
Fournir une interface unifiée à l'ensemble des
interfaces des sous-systèmes. L’interface fournie
est de plus haut niveau et rend le système plus
facile à utiliser.
 Problème :
◦ Bibliothèque complexe, avec beaucoup d'interfaces
◦ Complexité nécessaire pour des clients experts mais
inutile pour une majorité de clients
◦ On souhaite garder la puissance de la bibliothèque
tout en fournissant une interface simplifiée
 Façade (2)
 Solution proposée
 Façade (3)
 Structure générique
 Façade (4)
 Conséquences :
◦ La «façade» propose une interface simplifiée
◦ Elle connaît les détails du sous-système
◦ Le client envoie ses requêtes à la façade qui les
délègue aux composants du sous-système
◦ La liberté est laissée au client d'utiliser le jeu
d'interfaces bas niveau (le cas des experts)
 Relations avec d'autres patrons
◦ Singleton : souvent, un seul objet façade par
programme
 Poids-mouche (1)
 Objectif :
Partager des instances pour éviter un nombre
trop important.
 Problème :
◦ On souhaite gérer les options que l’acheteur peut
choisir quand il commande un nouveau véhicule
◦ Une option est caractérisée par un nom, une
description et un prix qui dépend du véhicule
◦ Un grand nombre d’options (objets de petite taille)
doit être géré alors que nombre d’entre elles
contiennent des données identiques
 Poids-mouche (2)
 Problème (suite)
 Poids-mouche (3)
 Solution proposée
◦ Séparation de l'état d'un objet en deux parties
 Etat intrinsèque: indépendant du contexte stocké
dans l'objet
 Etat extrinsèque: dépendant du contexte fourni en
paramètre par le client
 Poids-mouche(4)
 Solution proposée (suite) : Partage des options
 Poids-mouche (5)
 Solution proposée (suite) :

si l’option portant ce nom existe

dans le stock
alors la récupérer et la renvoyer.
sinon créer une nouvelle option
l’ajouter au stock puis la renvoyer
 Poids-mouche (6)
 Structure générique

si le poids-mouche portant cette clé

existe dans le stock
alors le récupérer et le renvoyer.
sinon créer une nouveau poids-mouche
l’ajouter au stock puis le renvoyer
 Poids-mouche (7)
 Conséquences :
◦ Evite la duplication inutile de données :
 Etat intrinsèque jamais dupliqué

 Relations avec d'autres patrons :

◦ Composite : peuvent être combinés pour obtenir
une arborescence avec feuilles partagées
 Proxy (1)
 Objectif :
Fournir un intermédiaire pour accéder à un objet
(sujet) et en contrôler l’accès
 Problème :
◦ Offrir la possibilité aux clients de visualiser les images
de véhicules se trouvant dans un catalogue.
◦ Le catalogue contient de nombreux véhicules il est
très lourd de créer en mémoire tous les objets
représentant les images (sujets)
◦ Solution : différer la création des sujets jusqu’au
moment où le système a besoin d’eux (e.g., clic sur
un bouton)
 Proxy (2)
 Solution proposée :

si (image = null)
alors image = new ImageReelle(nomFichier)
image.afficherImage()
 Proxy (3)
 Structure générique :
 Proxy (4)
 Conséquences :
◦ Le substitut, le «proxy», possède la même interface
que l'objet
◦ Lorsqu'il reçoit un message, il le transmet à l'objet
◦ Il peut effectuer un contrôle sur le message
 Refuser de le retransmettre (proxy de protection)
 Différer la retransmission
 Altérer le message
 Relations avec d’autres patrons :
◦ Décorateur: ajouter des fonctionnalités
◦ Proxy : contrôler les accès
 Quiz 3
Une maison d’édition produit différents types
de publications (livres, articles, …).
Ces publications sont distribués sur différents
supports (CD, DVD, version papier…).

Quel patron permet de modéliser

convenablement les deux hiérarchies
Publications et Supports?
 Quiz 4
Un employé est caractérisé par un nom et un
salaire, il peut être un développeur ou un
manager qui supervise d’autres employés.
 Quel patron de conception permet de
modéliser cette situation?
 Est-il aisé d’ajouter un nouveau type
d’employés (e.g. comptable, secrétaire)?
 Proposer une implémentation de la méthode
d’affichage ainsi qu’un programme principal
pour le test.
 Quiz 5
Genius coffee veut mettre en place un système
unifié de facturation pour ses points de vente.
Les cafés proposés sont de plusieurs types
(espresso, colombia …) et admettent de
nombreuses options (lait, chantilly, chocolat,
caramel,...) qui ont une influence sur le prix (lait
: +5dh, chocolat : +7dh …)
 En appliquant le patron de conception
Décorateur, proposer un diagramme de
classes convenable et expliquer comment le
calcul du prix final d’un café sera élaboré
 Patrons de comportement (1)
 Chaîne de responsabilité / Chain of Responsability
◦ Transmettre une requête de proche en proche jusqu'à
traitement
 Commande / Command
◦ Encapsuler une action dans un objet
 Interpréteur / Interpreter
◦ Représenter la grammaire d'un langage
 Itérateur / Iterator
◦ Fournir un accès séquentiel aux éléments d'un agrégat
 Médiateur / Mediator
◦ Encapsuler la manière d'interagir d'un groupe d'objets
 Patrons de comportement (2)
 Mémento / Memento
◦ Capturer et externaliser l'état d'un objet
 Observateur / Observer
◦ Synchroniser plusieurs objets sur l'état d'un autre objet
 Etat / State
◦ Changer le comportement d'un objet en fonction de son état
 Stratégie / Strategy
◦ Rendre les algorithmes d'une même famille interchangeables
 Méthode patron / Template Method
◦ Spécialiser un algorithme sans changer sa structure générale
 Visiteur / Visitor
◦ Représenter une opération à appliquer sur un ensemble
d'objets
 Méthode patron (1)
 Objectif :
Spécialiser un algorithme sans changer sa
structure générale
 Problème :
Recette pour préparer un café Recette pour préparer du thé

1. Faire bouillir de l'eau 1. Faire bouillir de l’eau

2. Filtrer le café à l’eau bouillante 2. Faire infuser le thé dans l'eau bouillante
3.Verser dans une tasse 3.Verser dans une tasse
4. Ajouter du lait et du sucre 4. Ajouter la menthe et du sucre

Les deux algorithmes ont le même squelette : ils partagent des

parties communes et possèdent des parties spécifiques
 Méthode patron (2)
 Solution proposée :
Abstraire les parties spécifiques pour retenir un
algorithme global générique (algorithme à trou)
bouillirEau( )
preparer( )
verserTasse( )
ajouterSupplément( )
 Méthode patron (3)
 Structure générique :

La classe parente
invoque les méthodes
des sous-classes. Ces
dernières n’effectuent
pas d’appel vers la
classe parente.
Principe de Hollywood
don’t call us, we will
call you!
 Méthode patron (4)
 Conséquences :
◦ Proposer plusieurs variantes d'un algorithme dont la
structure générale est inchangée
◦ Fixer clairement un comportement standard qui
devrait être partagé par toutes les sous-classes
◦ Mais éviter trop d'opérations primitives :
 Redéfinition fastidieuse pour l'utilisateur
 Implémentation :
◦ Appelée méthode socle et souvent déclarée final
(pour éviter sa redéfinition)
◦ Les opérations primitives (méthodes abstraites) sont
souvent déclarées protected (pour éviter de les
appeler directement)
 Observateur (1)
 Objectif :
◦ Construire une dépendance entre un objet
source (sujet) et des observateurs (abonnés).
◦ Quand le sujet change d’état :
 tous ses observateurs sont informés
 ils se mettent à jour
 Problème :
◦ Affichage en temps réel à partir de données
provenant d’une station météo (température,
humidité, pression)
 Observateur (2)
 Solution proposée :

pour chaque o de observateurs

o.actualiser()

modifier l’état de l’objet courant

notifier()
 Observateur (3)
 Diagramme de séquence :
 Observateur (4)
 Structure générique :

pour chaque o de observateurs

o.actualiser()

modifier l’état de l’objet courant

notifier()
 Observateur (5)
 Conséquences :
◦ Le type concret des observateurs n'est pas connu du
sujet :
 Ajout de nouveaux types d’observateurs facile
◦ Les observateurs sont passifs :
 Pas besoin d'interroger le sujet en permanence
 Informés quand le sujet change d'état

 Relations avec d'autres patrons :

◦ Modèle-Vue-Contrôleur (MVC)
 Modèle = sujet
 Vue = observateur
 Itérateur (1)
 Objectif :
Parcourir une collection d’éléments sans
accéder à sa structure interne
 Problème :
◦ La cafeteria stocke son menu de plats dans un
tableau, la pizzeria utilise une ArrayList
◦ Comment afficher les plats des deux menus?
for (int i = 0; i < platsPizza.size(); i++)
platsPizza.get(i).afficher();} Hétérogène et
redondant
for (int i = 0; i < platsCafet.length; i++)
platsCafet[i].afficher();}
 Itérateur (2)
 Solution proposée :

it =getIterator( )
tant que(it.estFini()=faux)
{it.suivant().affichage()}
 Itérateur (3)
 Structure générique :
 Itérateur (4)
 Conséquences :
◦ Abstraction de la structure de la collection
◦ Abstraction de la manière de parcourir
 Un type d'itérateur par type de parcours
◦ Simplification de l’interface de la collection
◦ Plusieurs parcours simultanés de la collection
sont possibles
 Relations avec d'autres patrons
◦ Composite : Itérateur souvent utilisé pour
parcourir l'arborescence
 Etat (1)
 Objectif :
Changer le comportement d'un objet en fonction
de son état
 Problème :
Le cycle de vie d’une commande passe par 3 états:
◦ En cours de constitution : on peut ajouter, supprimer
un produit, valider la commande
◦ Validée (réglée par le client) : la commande peut
être livrée. On ne peut plus ajouter/supprimer un produit
◦ Livrée : la livraison a lieu ! On ne peut ni ajouter un
produit ni le supprimer
La classe Commande contient des méthodes dont le
comportement dépend de l’état de la commande
 Etat (2)
 Solution proposée :

etat.ajouterProduit(p)
 Etat (3)
 Structure générique :
 Etat (4)
 Conséquences :
◦ Etats représentés sous forme d'objets qui
possèdent la même interface
◦ Un objet agrège un état :
 changement d'objet état  changement de comportement
◦ Possibilité d’ajouter ou de retirer des états et des
transitions de manière simple
◦ Plus besoin de traitements conditionnels
 Relations avec d’autres patrons :
◦ Poids-mouche : Les objets états peuvent être
partagés entre objets contextes
 Stratégie (1)
 Objectif :
Définir une famille d'algorithmes interchangeables pour
résoudre un même problème, et qui peuvent évoluer
indépendamment des applications qui les utilisent
 Problème :
◦ Proposer une variété d’algorithmes pour un même
objectif
◦ Possibilité de changer dynamiquement l’algorithme
◦ Exemple de tri : tri par sélection, tri par insertion, tri
rapide …
 Stratégie (2)
 Solution proposée :
 Stratégie (3)
 Structure générique :
 Stratégie (4)
 Conséquences :
◦ Le choix d’un algorithme se fait dynamiquement en
fonction du contexte (choix de l’utilisateur,
performance …)
◦ Possibilité de changer dynamiquement l’algorithme
◦ Ajout d’un nouvel algorithme facile : une nouvelle
classe dérivée de Stratégie
◦ Mais léger surcoût du à l’augmentation du nombre
d’objets (surtout s’il faut changer souvent de
stratégie)
 Relations avec d'autres patrons :
◦ Singleton : Les stratégies peuvent être des objets
uniques
 Quiz 6
Une personne possède un cycle au long de sa vie
professionnelle. Elle est d’abord étudiante puis
intègre la vie active puis prend sa retraite. Elle ne
cotise pour sa retraite que lors de sa vie active.
 Quel patron est le mieux adapté pour décrire
une personne au long de sa vie professionnelle?
 Proposer un diagramme de classes. Introduire
les deux méthodes suivantes :
◦ getSituation ( ) : String qui renvoie l’état actuel de la
personne (étudiant, salarié, retraité)
◦ ajouterPoints(int n) : void qui ajoute des points de
retraites pour les personnes qui ont une vie active
 Quiz 6 (suite)
Il s’agit maintenant de créer une interface
graphique qui affiche la personne ainsi que
son état professionnel. Chaque fois que les
données d’une personne sont changées
l’affichage dans l’interface graphique est mis à
jour automatiquement.
 Quel patron de conception est le mieux
adapté pour concevoir cette interface?
 Présenter le diagramme de classes complet
 Quiz 7
Le catalogue d’une société de vente de véhicules
comprend la description de toutes les voitures
mises en vente.
On souhaite laisser la liberté à l’utilisateur pour
choisir l’algorithme d’affichage du catalogue qui
lui convient (affichage vertical, horizontal, sous
forme de grille, etc)
 Quel patron est le mieux adapté pour
résoudre ce problème?
 Proposer un diagramme de classes en utilisant
ce patron