École Nationale des Sciences de l’Informatique

ACOO

Chapitre 4
II2-ENSI

1
 INTRODUCTION

 En conception, il n’est pas rare de faire

face à un problème qui a déjà été rencontré
et résolu par d’autres personnes.
 Réutiliser les solutions trouvées par ces
autres personnes permet de gagner non
seulement du temps mais aussi de la
qualité.
Recherche de solutions standards :

Les patrons de conception

.

2
 DESIGN PATTERN

« Une solution à un problème dans un contexte. »

 Contexte= Ensemble de situations récurrentes auxquelles le pattern

s’applique.
 Problème = Ensemble de buts et de contraintes qui se présentent dans
le contexte.
 Solution = Schéma de conception canonique ou règle de conception
qui peut être utilisé pour résoudre le problème.

• Les patrons sont décrits sous une forme abstraite, sans

s'attacher aux détails du problème à résoudre.

 Les
3
 DESCRIPTION DES PATRONS

Les Design Patterns sont représentés par :

 Nom: qui permet de l’identifier clairement

 Problématique: description du problème auquel il répond
 Solution: description de la solution souvent accompagnée
d’un schéma UML
 Conséquences : les avantages et les inconvénients de cette
solution
 Autres
 Exemples d’implantation
 Conseil d’implantation

Catalogue de patrons sur Internet:

http://sourcemaking.com/design_patterns
http://www.dofactory.com/Patterns/Patterns.aspx#list
4
 CLASSIFICATION DES PATTERNS

 Patterns de création: Solutions permettant de créer des objets

de façon flexible.

 Patterns structuraux: Solutions permettant d’organiser

l’agencement structurel d’un ensemble d’objets de façon à en
faciliter l’accès et la maintenance.
Comment composer classes et objets pour obtenir des structures
plus complexes

 Patterns comportementaux: Solutions permettant d’organiser

les interactions d’un ensemble d’objets de façon efficace et
facilement maintenable.
 PATRONS DE CRÉATION

 Abstract Factory : interface pour la création de familles d’objets

sans spécifier les classes concrètes.
 Builder : séparation de la construction d’objets complexes de leur
représentation afin qu’un même processus de construction puisse
créer différentes représentations.
 Factory Method : définition d’une interface pour la création
d’objets associés dans une classe dérivée.
 Prototype : spécification des types d’objet à créer en utilisant une
instance prototype.
 Singleton : comment assurer l’unicité de l’instance d’une
classe.
6
 PATRONS DE STRUCTURE

 Adapter : traducteur adaptant l’interface d’une classe en une autre

interface convenant aux attentes des classes clientes.
 Bridge : découplage de l’abstraction de l’implémentation pour faire varier
les deux indépendamment.
 Composite : structure pour la construction d’agrégations
récursives.
 Decorator : extension d’un objet de manière transparente.
 Façade : unification de plusieurs interfaces de sous-systèmes.
 Flyweight : partage efficace de plusieurs objets.
 Proxy : approximation d’un objet par un autre.

7
 PATRONS DE COMPORTEMENT

 Chain of Responsibility: délégation des requêtes à des responsables de services.

 Command: encapsulation de requêtes par des objets afin de permettre à un objet de
traiter plusieurs types de requêtes.
 Interpreter : étant donné un langage, représentation de la grammaire le définissant
pour l’interpréter.
 Iterator : parcours séquentiel de collections.
 Mediator : coordination d’interactions entre des objets associés.
 Memento : capture et restauration d ’états d’objets.
 Observer :mise à jour automatique des dépendants d’un objet.
 State : permettre à un objet de modifier son comportement lorsque son état interne
change.
 Strategy : abstraction pour sélectionner un algorithme parmi plusieurs.
 Visitor :représentation d’opérations devant être appliquées à des éléments d’une
structure hétérogène d’objets.
8
 SINGLETON: UN DESIGN PATTERN DE
CREATION

 Nom : Singleton
 Problème : Assurer qu’une classe ne
dispose que d’une unique instance Singleton
 Solution :
- instance: Singleton
 Rendre privé le constructeur,
 Construire une instance privée de la classe -Singleton ()
+ getInstance (): Singleton
comme attribut statique de la classe,
 Fournir une méthode publique d’accès à cette
instance.

9
 C O D E J AVA S I N G LETON

public class Singleton

{
private static Singleton instance = null ;

//La présence d’un constructeu r privé supprime le constructeu r public par défaut
private Singleton () {
}
// Retourne l’unique instance de cette classe .
public static Singleton getInstance ()
{
if (instance == null) instance = new Singleton ( );

return instance ;
}
}
10
CODE JAVA SINGLETON (AUTRE VERSION)

public class MonSingleton

{
private static final MonSingleton instance = new MonSingleton
() ;

//La présence d’un constructeu r privé supprime le constructeu r public par d

»faut
private MonSingleton () {
}
// Retourne l’unique instance de cette classe .
public static MonSingleton getInstance ()
{
return instance ;
}
}

11
 EXEMPLES

 Gestion centralisée d’une ressource :

_ un objet qui est un compteur « global »
_ un objet qui gère la réutilisation d’une connexion à une base de données
 Classes qui ne devraient avoir qu’une seule instance à la fois :
_ Horloge du système
_ Fenêtre principale d’une application
_ Générateur de nombre aléatoire (random number generator)

12
EXERCICE1: JOURNALISATION BANCAIRE

 Soit une classe CompteBancaire qui permet de déposer

ou retirer de l’argent sur un compte. On souhaiterait
pouvoir afficher les opérations (effectuées ou
refusées). Cette petite application devra rapidement
évoluer et il est fort probable que par la suite d’autres
classes soient concernées par cette journalisation.

Question : Implémentez une classe distincte nommée

Journal reprenant le patron Singleton.

13
 SOLUTION1/2

class Journal {
private static Journal instance = null;
private String ch="";
private Journal (){

static Journal getInstance (){

if (instance == null)
instance = new Journal ();
return (instance);
}

void operation (String s){

ch+=s +"\n";
}
}

14
 SOLUTION2/2

class CompteBanque{
private double solde;

void deposer (double m){

solde+= m;
Journal.getInstance().operation("Dépot"+m);

}
void retirer (double m){
solde-= m;
Journal.getInstance().operation("Retrait"+m);

}
}
class Test{

public static void main (String [] arg){

CompteBanque c = new CompteBanque();
c.deposer (5);
c.deposer (15);
c.retirer (5);
}
}

15
 COMPOSITE: UN EXEMPLE DE PATRON DE
CONCEPTION STRUCTUREL

 Nom : Composite
 Problème : établir des structures arborescentes entre des objets et
les traiter uniformément
 Solution : Agencer les objets dans une structure en arbre de façon
à définir une hiérarchie.

16
 COMPOSITE: UN EXEMPLE DE PATRON DE
CONCEPTION STRUCTUREL

 Conséquences :
Hiérarchies de classes dans lesquelles l’ajout de nouveaux
composants est simple: simplification du client qui n’a pas à se
préoccuper de l’objet accédé MAIS il est difficile de restreindre et
de vérifier le type des composants
 Exemple :
 java.awt.Component
 java.awt.Container

17
UN AUTRE EXEMPLE: AWT

Agrégation
ou
composition
EXEMPLE A IMPLEMENTER?

Agrégation
ou
composition
 OBSERVER: UN PATRON DE
COMPORTEMENT

Nom: Observer
Problème :
 Il est parfois extrêmement utile qu ’un objet puisse suivre en
continu l’état d’un autre objet.
 C’est en général à l’objet observé de faire tout le travail consistant
à prévenir ceux qui sont intéressés ( observateurs) par son
changement d’état.
-> Plus il y a d’observateurs, plus l’objet observé se trouve
fortement couplé.
Solution :
 Généralisation du savoir-faire de l’Observateur et de l’observé
(classe abstraite ou interface)
 Fournir à l’observé (Sujet) une gestion des Observateurs concrets.
 Permettre au sujet d’envoyer un message générique de notification
de son changement d’état à tous les Observateurs.

20
LE PATRON DE COMPORTEMENT: OBSERVER

Structure statique

<<Interface>>

21
LE PATRON DE COMPORTEMENT: OBSERVER

 Le Sujet
 Garde une trace de ses observateurs
 Propose des méthodes pour ajouter ou enlever des observateurs
 Le sujet concret
 C’est l’objet observé
 Enregistre son état intéressant les observateurs
 Envoie une notification à ces observateurs quand il change d ’état
 L’Observateur
 Définit une interface pour la notification de mises à jour
 L’Observateur concret
 Il observe l’objet concret
 Il implémente l’interface de mise à jour permettant à son état de
rester consistent avec celui de l’objet observé
 Il stocke l’état qui doit rester consistent avec celui de l’objet observé

22
 L’OBSERVATEUR ET L’OBSERVÉ GÉNÉRIQUES
interface Observateu r {
public void actualiser (Observé o); // Méthode update
}
abstract class Observé {
private ArrayList tabObserv ateu r = new ArrayList (); // Tableau d'observateu rs.

public void ajouterOb serv ateu r (Ob serv ateu r o) { // Méthode attach
tabObserv ateu r.add (o );
}

public void supprimerOb serv ateu r (Ob serv ateu r o) { //Méthod e detach
tabObserv ateu r.remov e (o ) ;
}

public void notifierObservateu rs ( ) { // Méthode notify

for(int i=0;i<tabObservateu r.size ();i++)
{
Observateur o = (Observ ateu r) tabOb serv ateu r.g et(i);
o.actualiser (th is );
} 23
 Exemple Exemple

Répercuter les changements de l’état d’un objet vers un ou plusieurs

autres objets (ex. : IHM, surveillance de données)
 CONCLUSION

Capitalisation de l’expérience
Un niveau d’abstraction plus élevé => Meilleure qualité
(plus de cohésion et moins de couplage)
Lisibilité et maintenance plus aisées

- Forcer l’utilisation d’un patron dans un logiciel est une

mauvaise pratique de développement
- Nécessite un apprentissage et de l’expérience (difficulté à
identifier quand un pattern s’applique, les patterns sont
nombreux)
 25