Patrons de Conception C++ PDF

Introduction Patrons comportementaux Patrons structuraux Patrons créationnels Les anti-patrons >
Les patrons de conception
Jean-Yves Didier
didier@ufrst.univ-evry.fr
nextHandler.handleRequest()
Handler
Client - nextHandler : Handler Si la requête peut être traitée,
+ handleRequest() alors traiter la requête, sinon :
super.handleRequest()
ConcreteHandler1 ConcreteHandler2
+ handleRequest() + handleRequest()
Jean-Yves Didier Les patrons de conception 1/70

1 Introduction
2 Patrons comportementaux
3 Patrons structuraux
4 Patrons créationnels
5 Les anti-patrons

Une boı̂te à outils pour les développeurs
Concept fondamentale de la POO

La réutilisation !
Patron de conception / design pattern

Solution éprouvée à des problèmes récurrents
Anti-patrons / anti-patterns
Diagnostic et résolution de dysfonctionnements

Choix dans un nouveau contexte de développement
Nouveau contexte
Faire quelque chose de neuf Puiser dans les retours d’expérience
Patrons de conception Anti-patrons

t on
len ti
ta ma
au ram
og
Pr
Avantages Avantages
Avantages et supérieurs aux inférieurs aux
conséquences aléatoires inconvénients inconvénients

Les patrons de conception (1/3)
Définition
• Description d’une solution classique à un problème récurrent ;
• Forme de capitalisation de l’expérience en génie logiciel.
Une formalisation abstraite

• Un patron de conception s’adapte ;
• Ne s’applique pas aveuglément ;
• Dépend de son contexte ;
• N’est pas une méthode en soit.

Avantages
• Vocabulaire formalisé ;
• Capitalisation de l’expérience ;
• Niveau d’abstraction élevé ;
• Complexité réduite ;
• Temps de conception et développement réduit ;
• Guide/catalogue de solutions.

Inconvénients
• Synthèse nécessaire :
I Comment reconnaı̂tre une situation où un patron s’applique ?
• Apprentissage :
I Catalogue volumineux : plus de 150 patrons répertoriés ;
I Différents niveaux : des patrons de patrons.
• Disparition du patron lors de son utilisation :

I Adaptation du patron à son contexte.

Bref historique
• 1977 – Christopher Alexander (architecte en bâtiment) ;

• 1995 – Livre : Design patterns – Elements of Reusable
Object-Oriented Software. Gamma, Helm, Johnson, Vlissides
I 23 patrons de conception introduits ;
I Auteurs connus sous le nom de Gang of Four (GoF).

Décrire les patrons de conception
Les points importants de la description

• Nom, autres dénominations connues,
• Description du problème à résoudre :
Objectifs, contexte du problème, exemples d’utilisation
I
• Description de la solution :
I Structure : diagramme de classes, de séquences,
I Participants (classes et objets) et collaborations,
I Description de la réalisation et exemple de code.
• Conséquences :
I Résultats, discussion avantages/inconvénients.

Principales familles de patrons de conception
Les patrons créationnels

Instanciation et configuration des classes et objets.
Les patrons structuraux

Organisation des classes dans une structure plus large.
Les patrons comportementaux

• Organisation des objets pour collaborer ;
• Fonctionnement des algorithmes appliqués.
D’autres familles
Les patrons gérant la concurrence, GRASP, . . .

Les 23 patrons du GoF
Création Structure Comportement

Abstract Factory Adapter Chain of responsability
Builder Bridge Command
Factory Method Composite Interpreter
Prototype Decorator Iterator
Singleton Facade Mediator
Flyweight Memento
Proxy Observer
State
Strategy
Template Method
Visitor

1 Introduction
5 Les anti-patrons

Chain of responsability (1/5)
Dénominations
Chain of responsability (Chaı̂ne de responsabilité), CoR,
intercepting filter
Contexte d’application
• Objectif :
I Déléguer un traitement à qui saura le réaliser ;
I Établir une chaı̂ne de filtres travaillant sur les mêmes données.
• Utilisation : (moyennement faible)
I Permet à un nombre quelconque de classes d’essayer de
répondre à une requête sans connaı̂tre les possibilités des

autres classes sur cette requête

Architecture de la solution
nextHandler.handleRequest()
Handler
Client - nextHandler : Handler Si la requête peut être traitée,
+ handleRequest() alors traiter la requête, sinon :
super.handleRequest()
ConcreteHandler1 ConcreteHandler2
+ handleRequest() + handleRequest()

Entités participantes
• Client
I Classe requérant le traitement ;
I L’initie sur une des classes ConcreteHandler.
• Handler
I Définit une interface pour répondre aux requêtes ;
I Implémente le passage au maillon suivant de la chaı̂ne.
• ConcreteHandler
I S’occupe de la requête dont il peut se charger ;
I Peut accéder à son successeur ;
I S’il ne peut satisfaire à une requête, il la passe au successeur.

Exemples d’utilisation
• Première version de la gestion des évènements en AWT
(Java) :
I Les évènements souris et claviers sont passés successivement
aux widgets jusqu’à trouver celui qui traite l’évènement.
I Le patron observateur lui a finalement été préféré.
• Les filtres pour les servlets JEE
I Classe Filter standard dans le paquetage javax.servlet
(v2.3) ;
I Permet d’appliquer à la chaı̂nes plusieurs filtres sur le
document produit avant sa transmission définitive ;

I Utilisation similaire avec ASP .Net

Avantages
• Faible couplage entre celui qui envoie la requête et celui qui la
gère réellement ;
• La chaı̂ne peut être modifiée dynamiquement.
Inconvénients
• Ne garantit pas qu’un requête sera traitée ;
• Acroit dangereusement le nombre d’objets actifs.

Iterator (1/6)
Dénomations
Iterator (Iterateur), cursor
• Objectif :
I Parcourir les éléments contenus dans un autre objet.
• Utilisation : (Elevée)
I Permet de parcourir une collection d’objets pour accéder
séquentiellement à tous ses éléments en vue d’appliquer des

traitements sur ces derniers ;
I Utilisé avec les structures d’arbres, de listes chaı̂nées, de tables
de hachage, et parfois aussi les tableaux.

Iterator (2/6)
Collection Iterator
+ getIterator() : Iterator + next()

+ addElement(elt : Element) Client + first()
+ removeElement(elt : Element) + hasFinished() : boolean
+ contains(elt : Element) : boolean + currentItem()
ConcreteCollection
ConcreteIterator
+ getIterator() : Iterator
return new ConcreteIterator(this) ;

Iterator (3/6)
• Iterator
I Définit une interface pour accéder et voyager parmi les
éléments.
• ConcreteIterator
I Réalise l’interface Iterator ;
I Conserve sa position courante dans la collection d’objets.
• Collection
I Définit une interface pour créer un objet de type Iterator.
• ConcreteCollection
I Réalise l’interface de Collection pour retourner une instance
de ConcreteIterator adaptée à la collection.

Iterator (4/6)
• Classes de base en C++ ! !
I Utilisée pour parcourir les classes issues de la STL (standard
template library) : vector, map, queue, list, etc.
• Interface présente en Java dans le paquetage
java.util :
I Sert à parcourir les classes Collection, Map, HashTable, etc

Iterator (5/6)

Iterator (6/6)
Avantages
Découple les algorithmes de parcours des collections qui
contiennent les éléments.
Inconvénients
Mène parfois à une violation du principe d’encapsulation et expose
les structures et les algorithmes de parcours à des effets de bord
non sollicités.

Observer (1/6)
Dénominations
Observer (observateur), publish/suscribe
• Objectif :
I Observer l’état d’un objet dans un programme ;
I Notifier un changement dans un objet à un autre sans que les
deux ne se connaissent à priori.
• Utilisation :
I Réalisation d’un système distribué de réception et de
traitement des évènements ;

I Applications temps réel.

Observer (2/6)
Subject
- observers : Observer[*]
Observer
+ getState()
+ notify() 1..1 0..* + registerObserver(obs : Observer)
+ unregisterObserver(obs : Observer)
+ notifyObserver()
notifyObservers() :
pour tout Observer
dans observers, appe-
ler notify()
ConcreteObserverA ConcreteObserverB ConcreteSubject
+ notify() + notify() + getState()

Observer (3/6)
• Subject
I Possède une interface pour attacher/détacher les observateurs ;
I Possède une liste privée d’observateurs.
• ConcreteSubject
I Implémente l’interface Subject, en particulier getState() ;
I L’objet observé en est une instance.
• Observer
I Définit une interface de mise à jour pour les observateurs ;
I Classe abstraite (à tout le moins l’opération notify).
• ConcreteObserver
I Le véritable observateur qui reçoit les évènements ;
I Surcharge l’opération notify.

Observer (4/6)
• Utilisé à plusieurs reprises dans Java ;
I Dans les évènements envoyés par les éléments de l’interface
graphique (mécanisme des écouteurs) ;
I Sous la forme de la classe abstraite Observable et de
l’interface Observer (paquetage java.util).
• Framework Qt (interface graphiques) en C++ :
I Mécanisme signal/slot.
• Traitement des évènements javascript.

Observer (5/6)
AbstractButton
ActionListener # actionListener : ActionListener
+ addActionListener(al : ActionListener)
+ actionPerformed(e : ActionEvent) + removeActionListener(al : ActionListener)
+ fireActionPerformed(e : ActionEvent)
Réalise
MyActionListener
JButton
+ actionPerformed(e : ActionEvent)
Avantages
• Séparation entre Observateur et Objet d’observation ;
• Relation dynamique entre les deux éventuellement établie à
l’exécution ;
• Communication de masse (broadcast / multicast).

Observer (6/6)
Inconvénients
• Mises à jour intempestives ;
• Circuit des mises à jour parfois difficile à déboguer.

Strategy (1/5)
Dénominations
Strategy
• Objectif :
I Sélectionner à la volée (lors de l’exécution) des algorithmes à
appliquer sous certaines conditions ;
I Fournit des moyens de définir des familles d’algorithmes.
• Utilisation :
I Situation où il est nécessaire de permuter dynamiquement les
algorithmes utilisés dans une application ;

I Un algorithme utilise des données qu’un client ne doit pas
connaı̂tre.

Strategy (2/5)
Context Strategy
1..1 1..1
+ concreteInterface() + algorithmInterface()
ConcreteStrategyA ConcreteStrategyB
concreteInterface() :
appelle algorithmInterface()
+ algorithmInterface() + algorithmInterface()

Strategy (3/5)
• Strategy
I Interface définissant le comportement de la stratégie.
• ConcreteStrategy
I Implémente l’interface Strategy.
• Context
I Va utiliser l’interface Strategy.

Strategy (4/5)
Exemple d’utilisation
Border
JComponent
+ paintBorder(. . .)
- border : Border -border + getBorderInsets(. . .)
+ isBorderOpaque()
AbstractBorder
BevelBorder TitledBorder
CompoundBorder LineBorder
EmptyBorder EtchedBorder
SoftBevelBorder
MatteBorder

Strategy (5/5)
Avantages
• Dispense de l’utilisation de déclarations conditionnelles ;
• Fournit un choix d’implémentations pour un même
comportement ;
• Permet de faire de l’héritage dans des langages qui ne le
permettent pas (ex : C).
Inconvénients
• Les stratégies ne font pas forcément usage de tous les
éléments passés par le contexte ;
• Prolifération d’objets.

1 Introduction
5 Les anti-patrons

Adapter (1/6)
Dénominations
adapter (adaptateur), wrapper
• Objectif :
I Convertir l’interface d’une classe en l’interface attendue de la
part d’un client.
• Utilisation : (Moyennement élevée)
I Lorsque l’on veut normaliser l’utilisation d’anciennes classes
sans pour autant les modifier ;

I Adaptation d’une API tiers dont la signature des opérations ne
convient pas.

Adapter (2/6)
Target
Client
+ request()
Adapter Adaptee
+ request() + specificRequest()
adaptee.specificRequest()

Adapter (3/6)
• Target
IDéfinit l’interface ciblée par le client.
• Adapter
I Adapte l’interface d’Adaptee pour la rendre compatible avec
celle de Target.
• Adaptee
I Définit une interface existante qui nécessite adaptation.
• Client
I Collabore avec les objets en utilisant l’interface définie dans
Target.

Adapter (4/6)
• Transformer une classe standard en Applet (Java) ;
• Rendre un objet distribuable via le réseau (Java – RMI) ;
• Classes anonymes (Java) :
p u b l i c c l a s s ButtonDemo {
p u b l i c ButtonDemo ( ) {
B u t t o n b u t t o n = new J B u t t o n ( " Press me " ) ;
button . addActionListener (
new A c t i o n L i s t e n e r ( ) {
public void actionPerformed ( ActionEvent e ) {
doOperation () ;
} } );
}
public void doOperation () { . . . }
}

Adapter (5/6)
Client et Adaptee Target
ButtonDemo
ActionListener
+ ButtonDemo() : ButtonDemo
+ doOperation()
Classe anonyme : Adapter

Adapter (6/6)
Avantage
Permet d’intégrer des objets existants dans de nouvelles structures
de classes sans être limité par leur interface.
Inconvénients
Surcoût en taille de code et en temps de calcul dû à l’appel des
opérations intermédiaires.

Composite (1/6)
Dénomination
Composite
• Objectif :
I Permet à un groupe d’objets d’être traités de la même manière
qu’un seul objet.
• Utilisation :
I Quand plusieurs objets sont utilisés de la même manière ;
I Pour représenter une hiérarchie d’objets ;
I Utile si la différenciation n’est pas un vrai besoin.

Composite (2/6)
Component
+ operation()
Composite
Leaf
+ operation()
+ add()
+ operation() + remove()
+ getChildren()

Composite (3/6)
• Component
I Est une abstraction de tous les composants ;
I Déclare l’interface des objets dans la composition ;
I Réalise le comportement commun par défaut ;
I Déclare une interface pour gérer les composants fils ;
I (Optionnel) Déclare une interface pour accéder aux parents.
• Leaf
I Représente une feuille de l’arbre (composant terminal).
• Composite
I Représente un composant composite (ayant des enfants) ;
I Réalise les opérations de manipulation des enfants ;
I Réalise les opérations de Component, généralement en les
délégant à ses enfants.

Composite (4/6)
• La hiérarchie des widgets graphiques en Java ;
• Description des noeuds de graphes de scènes dans
OpenInventor (C++).
Component
Label Checkbox Button Canvas Container
Hiérarchie des widgets en Java

Composite (5/6)
SoNode
SoLight ... SoMaterial SoFont SoGroup
SoSwitch SoSeparator
Hiérarchie des noeuds dans les graphes de scène Inventor

Composite (6/6)
Avantages
• Facilite l’ajout de nouveaux composants ;
• Facilite l’écriture d’un client gérant ces objets ;
• Le client n’a pas connaissance du type (feuille ou composant
composite).
Inconvénient
• Rend la rectriction des types de composants composite
difficile.

1 Introduction
5 Les anti-patrons

Prototype (1/4)
Dénomination
Prototype
• Objectif :
I Spécifie le type d’objet à créer en utilisant un prototype
d’instance et créer de nouveaux objets en clonant le prototype.
• Utilisation : (moyenne)
I Utile si l’initialisation d’un objet est coûteuse en temps ;
I Ne requiert pas une classe, mais un objet.

Prototype (2/4)
Prototype
Client
+ clone() : Prototype
ConcretePrototype1 ConcretePrototype2
+ clone() : ConcretePrototype1 + clone() : ConcretePrototype2

Prototype (3/4)
• Prototype
I Déclare une interface permettant de se cloner elle-même.
• ConcretePrototype
I Réalise l’interface Prototype afin de se cloner soi-même.
• Client
I Crée un nouvel objet par clonage via le prototype.
Exemple d’utilisation
La classe Object de Java
• Contient une méthode clone() ;
• À surcharger pour rendre n’importe quel type d’objet clonable.

Prototype (4/4)
Avantage
• Permet de créer des classes par clonage, ce qui peut s’avérer
plus rapide dans certains cas que la création par le biais d’un
constructeur classique.
Inconvénients
• Peu adapté dans le cas où l’on maintient des références à
d’autres objets ;
• Chaque prototype doit être instancié de manière classique une
fois, ce qui peut être un frein à la performance ;
• Requiert des objets à cloner une panoplie complète
d’accesseurs.

Singleton (1/4)
Dénomination
Singleton
• Objectif :
I S’assure qu’une classe possède une seule instance et fournit un
accès global à cette dernière.
• Utilisation : (moyennement élevée)
I Dans tous les cas où une seule instance de la classe est
nécessaire ;
I Pour contrôler l’accès à une ressource partagée (file
d’impression, connexion à une base de donnée, . . .).

Singleton (2/4)
-instance
Singleton
- instance : Singleton
- Singleton()
+ getInstance() : Singleton
Entité participante
• Singleton
I Emploie un constructeur à visibilité privée ;
I Possède un attribut de classe de type Singleton ;
I Donne accès à ce dernier via getInstance().

Singleton (3/4)
Utilisé à trois reprises dans l’API Java :
• Classe Runtime donnant accès, pour l’application, à son
environnement d’exécution ;
• Classe Desktop pour lancer des actions liées au bureau
(interface graphique) dans lequel l’application est lancée ;
• Classe Toolkit qui lie les widgets Java et leur implémentation
native dans le système d’exploitation.

Singleton (4/4)
Avantages
• Facile à mettre en oeuvre ;
• Adapté pour certaines classes de test unitaire.
Inconvénients
• Le plus controversé des patrons de conception : souvent un
euphémisme pour les variables globales ;
• Doit être implémenté avec précaution dans un environnement
multi-threadé.

1 Introduction
5 Les anti-patrons

Les anti-patrons
Concept
• Extension naturelle de patrons de conception ;
• S’intéressent à la problématique du refactoring :
I Décrivent des synptômes (dysfonctionnements) ;
I Indiquent la recette à appliquer pour corriger l’application.
• Sont moins formalisés que les patrons de conception ;
• Sont au nombre d’une quarantaine.
Des noms folkloriques

Programmation spaghetti, blob, usine à gaz, shotgun debugging,
culte du cargo, etc.

La programmation spaghetti (1/5)
Dénominations connues
Programmation spaghetti, code spaghetti, grosse boule de boue
(big ball of mud), etc.
Définition – Code spaghetti

Code dans lequel le contrôle du flux de données est emmêlé
comme un plat de spaghettis. Partie de logiciel ou de programme
qui ne peut être modifiée ou étendue qu’avec difficulté en raison de
sa structure mal définie.

Des surprises, parfois bonnes, souvent mauvaises
Disney,
c La belle et le clochard Robert
c Labay, Flickr


Contexte / symptômes
• Maquette de programme devenue l’application elle-même ;
• Programmeur solitaire ;
• Documentation obsolète ou insuffisante ;
• 50% de la maintenance passée en redécouverte ;
• Contournements et détournements de la part de l’utilisateur.
Impacts sur le code source

• Nombreux objets avec des opérations sans paramètres ;
• Variables et classes globales suspicieuses ;
• Relations entre objets obscures et imprévisibles ;
• Avantages de la programmation objet perdus.
Code plus facile à réécrire qu’à maintenir !

Solution de refactoring
1 Extraire les généralisations ;
2 Détailler les spécifications ;

3 Expliciter les relations entre classes ;
4 Modifier le comportement des développeurs.
Extraire les généralisations

• Identifier les classes aux comportements similaires ;
• Homogénéiser les signatures de leurs opérations ;
• Créer une super-classe avec ces opérations ;
• Homogénéiser le code, puis le factoriser.

Détailler les spécialisations

• Utiliser des patrons de conception tels que Strategie ou
l’Inversion de dépendances ;
• Identifier les parties de code spécifiques ;
• Créer les sous-classes correspondantes.
Modifier le comportement des développeurs

• Promouvoir le développement incrémental ;
• Documenter le code ;
• Se cadrer sur une architecture de référence ;
• Pousser à l’utilisation des patrons de conception.

Le Blob (1/3)
Dénominations connues
Blob, god object (objet divin)

Le Blob (2/3)
Contexte / symptôme
• Classe avec de nombreux attributs/opérations ;
• Classe de contrôle assistée de classe périphérique de données ;
• Peu de principes de la POO appliqués : en particulier violation
du principe Single responsability de SOLID.
Conséquences
• Perte des avantages liés à la POO ;
• Objet trop complexe à réutiliser ou tester ;
• Objet lourd en terme d’occupation mémoire.

Le Blob (3/3)
Solutions
• Identifier les responsabilités contenues dans la classe ;
• Décomposer le blob en classes traitant chacune un nombre
limité de responsabilités.

Le culte du cargo (1/2)
Dénominations connues ou apparentées

Culte du cargo, programmation vaudoue, programmation par
copier-coller
Origine de l’appelation
Culte réel ayant émergé en Mélanésie après la seconde guerre
mondiale.

Le culte du cargo (2/2)

Définition
Consiste en copier quelque chose sans vraiment comprendre ou en
ignorant les principes sous-jacents qui font que la solution originelle
est opérationnelle mais inadaptée au problème posé.
Contexte / Symptômes
• Instructions inutiles / contre-productives dans le code source ;
• Faible expérience de l’équipe de développeurs.
Un problème de ressources humaines plus que de code !
Solutions
• Nettoyer le code, en retirer les portions inutiles ;
• Former les développeurs.

Conclusion
Synthèse
• Catalogue de solutions de conception : patrons de conception ;
• Catalogue de solutions de refactoring : les anti-patrons.
Critiques
• Patrons de conception : haut niveau d’abstraction ;
• Une réutilisation peu aisée ;
• Utiliser les patrons de conception à outrance est un
anti-patron.

References
Cunningham, W. (2013).
Anti patterns catalog.
http://c2.com/cgi/wiki?AntiPatternsCatalog.
Gamma, E., Helm, R., Johnson, R. et Vlissides, J. (1994).
Design patterns : elements of reusable object-oriented
software.
Pearson Education.

Patrons de Conception C++ PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Patrons de Conception C++ PDF

Загружено:

Авторское право:

Доступные форматы

Introduction Patrons comportementaux Patrons structuraux Patrons créationnels Les anti-patrons >

Les patrons de conception

Jean-Yves Didier Les patrons de conception 1/70

Jean-Yves Didier Les patrons de conception 2/70

Une boı̂te à outils pour les développeurs

Concept fondamentale de la POO

Patron de conception / design pattern

Jean-Yves Didier Les patrons de conception 3/70

Choix dans un nouveau contexte de développement

Faire quelque chose de neuf Puiser dans les retours d’expérience

Patrons de conception Anti-patrons

Jean-Yves Didier Les patrons de conception 4/70

Les patrons de conception (1/3)

Une formalisation abstraite

Jean-Yves Didier Les patrons de conception 5/70

Les patrons de conception (2/3)

Jean-Yves Didier Les patrons de conception 6/70

Les patrons de conception (3/3)

I Différents niveaux : des patrons de patrons.

• Disparition du patron lors de son utilisation :

Jean-Yves Didier Les patrons de conception 7/70

• 1977 – Christopher Alexander (architecte en bâtiment) ;

Jean-Yves Didier Les patrons de conception 8/70

Décrire les patrons de conception

Les points importants de la description

Jean-Yves Didier Les patrons de conception 9/70

Principales familles de patrons de conception

Les patrons créationnels

Les patrons structuraux

Les patrons comportementaux

Jean-Yves Didier Les patrons de conception 10/70

Les 23 patrons du GoF

Création Structure Comportement

Jean-Yves Didier Les patrons de conception 11/70

Jean-Yves Didier Les patrons de conception 12/70

Chain of responsability (1/5)

répondre à une requête sans connaı̂tre les possibilités des

Jean-Yves Didier Les patrons de conception 13/70

Chain of responsability (2/5)

Jean-Yves Didier Les patrons de conception 14/70

Chain of responsability (3/5)

I Implémente le passage au maillon suivant de la chaı̂ne.

I S’il ne peut satisfaire à une requête, il la passe au successeur.

Jean-Yves Didier Les patrons de conception 15/70

Chain of responsability (4/5)

document produit avant sa transmission définitive ;

Jean-Yves Didier Les patrons de conception 16/70

Chain of responsability (5/5)

Jean-Yves Didier Les patrons de conception 17/70

séquentiellement à tous ses éléments en vue d’appliquer des

de hachage, et parfois aussi les tableaux.

Jean-Yves Didier Les patrons de conception 18/70

+ getIterator() : Iterator + next()

return new ConcreteIterator(this) ;

Jean-Yves Didier Les patrons de conception 19/70

de ConcreteIterator adaptée à la collection.

Jean-Yves Didier Les patrons de conception 20/70

Jean-Yves Didier Les patrons de conception 21/70

Jean-Yves Didier Les patrons de conception 22/70

Jean-Yves Didier Les patrons de conception 23/70

traitement des évènements ;

Jean-Yves Didier Les patrons de conception 24/70

ConcreteObserverA ConcreteObserverB ConcreteSubject