Conception OO Design Pattern
Hafidi Imad-ENSAK-Cours PD 1
Processus de Développement Analyse & conception OO
Pr Hafidi Imad [email protected]
Troisième partie
Hafidi Imad-ENSAK-Cours PD 2
Conception Orienté Objet
But � L'objectif de cette partie est :
� de faire un rappel sur les connaissances acquises sur la modélisation objet.
� d'introduire la notion de conception orientée objet par rapport à l'analyse orientée objet.
� d'approfondir le concept d'interface. � d'établir les deux grands principes de la conception orientée
objet � Programmation générique plutôt que programmation spécifique � Réutiliser par la composition plutôt que par l'héritage
Hafidi Imad-ENSAK-Cours PD 3
Analyse et conception L'analyse consiste sur la base d'un cahier de charge de modéliser
les acteurs et le système en ne s'intéressant pas à l'implémentation. On parle d'approche Métier.
QUI (acteurs) fait QUOI (système)
La conception consiste sur la base de l'analyse à modéliser la réalisation informatique. On parle d'approche informatique :
COMMENT ?
Hafidi Imad-ENSAK-Cours PD 4
Rappelles sur l’approche Objet � Un objet réunit des données(attributs) et des
opérations(méthodes) qui opèrent sur ces données. � Un objet réalise une opération lorsqu'il reçoit une
requête(ou message) de la part d'un client. � Les requêtes sont les seuls moyens de faire exécuter une
opération. Les opérations sont les seuls moyens de modifier les données internes d'un objet.
Hafidi Imad-ENSAK-Cours PD 5
Les grands principes de l’orienté objet � L'encapsulation: la structure interne d'un objet n'est pas
connu de l'extérieur (intégrité garantie d'un bon développement).
� L'héritage: une classe dite dérivée contient les attributs et opérations d'une classe existante (une façon de réutiliser).
� Le polymorphisme est la possibilité d'envoyer une requête à un objet sans connaître de type de l'objet.
Hafidi Imad-ENSAK-Cours PD 6
Généralité sur la conception orienté objet
La tâche essentielle et difficile de la conception orientée objet est la décomposition d'un système en
objets.
Hafidi Imad-ENSAK-Cours PD 7
� La difficulté tient à plusieurs facteurs conflictuels : � Encapsulation : un objet n'est accessible de l'extérieur qu'à
travers son interface. � Granularité :les objets sont plus ou moins fins � Dépendance : les objets doivent communiquer entre eux � Performance : l’exécution doit être la plus rapide possible � Réutilisabilité : On doit pouvoir réutiliser des objets dans des
programmes différents
Hafidi Imad-ENSAK-Cours PD 8
Des objets peuvent varier en taille. Un objet représentant une
application est plus gros qu'un objet qui représente un élément de bas niveau comme du matériel (souris, clavier) ou
un conteneur (liste, vecteur, arbre).
Comment déterminer la granularité d'un objet et par la même quelles sont ses responsabilités ?
Hafidi Imad-ENSAK-Cours PD 9
� Des objets peuvent représenter des entités du monde réel comme des étudiants mais d'autres n'existent pas dans la réalité comme des processus.
� La modélisation orientée objet permet à travers une même approche (celle de l'objet) de tout représenter. L'abstraction est donc obligatoire.
Hafidi Imad-ENSAK-Cours PD 10
Opération et interface d’un objet � La déclaration d'une opération d'un objet est constituée
� du nom de l'opération � ses paramètres reçus � du retour
� Cet ensemble est la signature de l'opération. � L'ensemble des signatures des opérations publiques d'un objet
est appelée interface de l'objet.
Hafidi Imad-ENSAK-Cours PD 11
Interfaces et interface d’un objet � Une requête d'un client à un objet x conforme à une
signature de l'interface de x peut être envoyée à x. � Rappel : Une interface est un ensemble de déclarations
d'opérations publiques. C'est un ensemble de services. � Rappel : Un classe réalise une interface I quand elle
implémente toutes les opérations déclarées dans I.
Hafidi Imad-ENSAK-Cours PD 12
� Si un objet réalise une interface I alors I est contenu dans l'interface de l'objet.
� Un objet O peut contenir plusieurs interfaces. Deux clients peuvent utiliser différemment l'objet O. � Le client simulateur de course de voitures a besoin de connaître
les services de fonctionnement d'une voiture. � Le client réparateur de voiture a besoins de connaître les
services de diagnostics de pannes et d'accès aux pièces de la voiture.
Hafidi Imad-ENSAK-Cours PD 13
� Des objets de types différents peuvent avoir une ou plusieurs interfaces en commun. � Un simulateur de vol d'avions peut faire voler des F18 ou des
canards Colvert du moment que ces objets fournissent les services demandés par les simulateur.
� L'ensemble des déclarations de ces services sera une interface commune entre un F18 et un canard Colvert.
� Les objets de type F18 et de type CanardColvert réalisent cette interface.
Hafidi Imad-ENSAK-Cours PD 14
Implémentation du polymorphisme � Quand un client envoie une requête à un objet x, il a
simplement besoin de savoir que cet objet peut recevoir cette requête.
� Les langages orientés objets comme le C++, Java et d'autres possèdent un mécanisme dit de liaison dynamique :
� L'opération à exécuter suite à une requête envoyée à un objet n'est connue qu'à l'exécution.
Hafidi Imad-ENSAK-Cours PD 15
� Si le client utilise les services d'un objet O et que ces services sont définis dans l'interface I alors l'objet O peut être déclaré de type I.
� Les conséquences sont : � l'interface de O contient I. � La classe de O doit réaliser l'interface I � Le client ne connaît pas le vrai type de O.
Hafidi Imad-ENSAK-Cours PD 16
1 principe de la conception orienté objet
� En résumé : Le client peut ignorer les classes d'objets qu'il utilise pour peu que les objets contiennent les interfaces utilisées par le client. Cela nous amène au premier principe de la conception orientée objet.
Programmer pour une interface, non pour un
développement particulier
Hafidi Imad-ENSAK-Cours PD 17
Classe abstraite � Une classe abstraite A est une classe dont certaines
opérations sont déclarées et non définies (comme pour les interfaces)
� On ne peut pas instancier des classes abstraites � Les classes concrètes qui dérivent de la classe A doivent
définir les méthodes abstraites déclarées dans A.
Hafidi Imad-ENSAK-Cours PD 18
Classe abstraite et polymorphisme � Dans certains cas, une requête peut connaître un objet à
travers une référence d'une classe abstraite A. � Il faut que la classe de l'objet dérive de la classe abstraite et
que l'opération soit contenue dans l'interface de la classe A.
Hafidi Imad-ENSAK-Cours PD 19
Concevoir pour mieux réutiliser � Deux techniques : � L'héritage: réutilisation boîte blanche. On parle de boîte
blanche, car le contenu des classes parentes est visible aux sous classes
� La composition: réutilisation boîte noire . On parle de boîte noire, car la nouvelle classes n'a pas accès à la représentation interne de l'objet réutilisé.
Hafidi Imad-ENSAK-Cours PD 20
L’héritage � L'héritage et ses principes
� Il est défini de façon statique à la compilation � L'utilisation dans la sous classe est immédiate � La sous classe peut surcharger quelques opérations tout en
gardant l'accès à la version de la classe Parent. � La sous classe dépend des changements de la classe Parent.
L'héritage rompt l'encapsulation. � Impossibilité de modifier à l'exécution le code hérité des
parents
Hafidi Imad-ENSAK-Cours PD 21
La composition � La composition et ses principes
� Notation : le nouvel objet sera appelé objet composé. � La composition est définie dynamiquement à l'exécution � L'accès des objets (composants) entrant dans la composition se
fait par l'intermédiaire d'une de leurs interfaces. � L'encapsulation des composants est totalement respectée � A l'exécution, chaque composant peut être remplacé par un
autre composant pourvu que le nouveau composant contienne l'interface utilisée.
� Il faut que les composants contiennent les interfaces utilisées dans l'objet composé.
Hafidi Imad-ENSAK-Cours PD 22
2 principe de la conception orienté objet
Pour la réutilisabilité, savoir différencier
l'héritage sémantique de l'héritage fonctionnel
S'il s'agit uniquement d'un héritage fonctionnel , il faut impérativement
utiliser la composition.
Hafidi Imad-ENSAK-Cours PD 23
Hafidi Imad-ENSAK-Cours PD 24
Designs Pattern
Objectifs
Hafidi Imad-ENSAK-Cours PD 25
� Modularité � Facilité de gestion (technologie objet)
� Cohésion � Degré avec lequel les tâches réalisées par un seul module sont
fonctionnellement reliées � Une forte cohésion est une bonne qualité
� Couplage � Degré d’interaction entre les modules dans le système � Un couplage ’’ lâche’’ est une bonne qualité
� Réutilisabilité � Bibliothèques, frameworks (cadres)
Cohésion : Mauvais exemple
Hafidi Imad-ENSAK-Cours PD 26
Cohésion : bon exemple
Hafidi Imad-ENSAK-Cours PD 27
Couplage : exemple
Hafidi Imad-ENSAK-Cours PD 28
Exemple : Tri Etudiants
Hafidi Imad-ENSAK-Cours PD 29
Solution 1
Hafidi Imad-ENSAK-Cours PD 30
Solution 2
Hafidi Imad-ENSAK-Cours PD 31
Définition : Pattern
Hafidi Imad-ENSAK-Cours PD 32
Un patron décrit à la fois un problème qui se produit très fréquemment dans l’environnement et l’architecture de la solution à ce problème de telle façon que l’on puisse utiliser cette solution des milliers de fois sans jamais l’adapter deux fois de la même manière.
Décrire avec succès des types de solutions récurrentes à des problèmes communs dans des types de situations
Hafidi Imad-ENSAK-Cours PD 33
� Documentation d’une expérience éprouvée de conception � Identification et spécification d ’abstractions qui sont au
dessus du niveau des simples classes, instances � Vocabulaire commun et aide à la compréhension de principes
de conception � Moyen de documentation de logiciels � Aide à la construction de logiciels répondant à des propriétés
précises, de logiciels complexes et hétérogènes � Traductions : patrons de conception, schémas de conception
Catégories de Pattern
Hafidi Imad-ENSAK-Cours PD 34
� Architectural Patterns � schémas d’organisation structurelle de logiciels (pipes, filters, brokers,
blackboard, MVC, …) � Design Patterns
� caractéristiques clés d’une structure de conception commune à plusieurs applications,
� Portée plus limitée que les « architectural patterns » � Idioms ou coding patterns
� solution liée à un langage particulier � Anti-patterns
� mauvaise solution ou comment sortir d ’une mauvaise solution � Organizational patterns
� Schémas d’organisation de tout ce qui entoure le développement d’un logiciel (humains)
Catégories de Design Pattern
Hafidi Imad-ENSAK-Cours PD 35
� Création � Description de la manière dont un objet ou un ensemble d’objets
peuvent être créés, initialisés, et configurés � Isolation du code relatif à la création, à l’initialisation afin de rendre
l’application indépendante de ces aspects � Structure
� Description de la manière dont doivent être connectés des objets de l’application afin de rendre ces connections indépendantes des évolutions futures de l’application
� Découplage de l’interface et de l’implémentation de classes et d’objets
� Comportement � Description de comportements d’interaction entre objets � Gestion des interactions dynamiques entre des classes et des objets
Présentation d’un Design Pattern
Hafidi Imad-ENSAK-Cours PD 36
� Nom du pattern � utilisé pour décrire le pattern, ses solutions et les conséquences en
un mot ou deux � Problème
� description des conditions d ’applications. Explication du problème et de son contexte
� Solution � description des éléments (objets, relations, responsabilités,
collaboration) permettant de concevoir la solution au problème ; utilisation de diagrammes de classes, de séquences, …
� vision statique ET dynamique de la solution � Conséquences
� description des résultats (effets induits) de l ’application du pattern sur le système (effets positifs ET négatifs)
Hafidi Imad-ENSAK-Cours PD 37
Designs Pattern de création
Design Pattern de création
Hafidi Imad-ENSAK-Cours PD 38
� Rendre le système indépendant de la manière dont les objets sont créés, composés et représentés � Encapsulation de la connaissance des classes concrètes à utiliser � Cacher la manière dont les instances sont créées et combinées
� Permettre dynamiquement ou statiquement de préciser QUOI (l’objet), QUI (l’acteur), COMMENT (la manière) et QUAND (le moment) de la création
� Deux types de motifs � 1. Motifs de création de classe (utilisation de l’héritage) :
Factory � 2. Motifs de création d’objets (délégation de la construction à
un autre objet) : AbstractFactory, Builder, Prototype
Singleton � Problème
� avoir une seule instance d’une classe et pouvoir l’accéder et la manipuler facilement
� Solution � une seule classe est nécessaire pour écrire ce motif
� Conséquences � l’unicité de l’instance est complètement contrôlée par la classe
elle même. Ce motif peut facilement être étendu pour permettre la création d’un nombre donné d’instances
39 Hafidi Imad-ENSAK-Cours PD
40 Hafidi Imad-ENSAK-Cours PD
Exemple : Labyrinthe
Hafidi Imad-ENSAK-Cours PD 41
42 Hafidi Imad-ENSAK-Cours PD
Factory Méthode � Problème
� ce motif est à utiliser dans les situations où existe le besoin de standardiser le modèle architectural pour un ensemble d’applications, tout en permettant à des applications individuelles de définir elles-mêmes leurs propres objets à créer
� Conséquences � + Elimination du besoin de code spécifique à l’application dans
le code du framework (uniquement l’interface du Product) � – Multiplication du nombre de classes
43 Hafidi Imad-ENSAK-Cours PD
Solution
44 Hafidi Imad-ENSAK-Cours PD
45 Hafidi Imad-ENSAK-Cours PD
Abstract Factory
Hafidi Imad-ENSAK-Cours PD 46
� Problème � ce motif est à utiliser dans les situations où existe le besoin de travailler avec
des familles de produits tout en étant indépendant du type de ces produits doit être configuré par une ou plusieurs familles de produits
� Conséquences � +Séparation des classes concrètes, des classes clients
� les noms des classes produits n’apparaissent pas dans le code client � Facilite l’échange de familles de produits � Favorise la cohérence entre les produits
� + Le processus de création est clairement isolé dans une classe � – la mise en place de nouveaux produits dans l’Abstract Factory n’est pas
aisée
� • Exemple � java.awt.Toolkit
Hafidi Imad-ENSAK-Cours PD 47
Hafidi Imad-ENSAK-Cours PD 48
Builder
Hafidi Imad-ENSAK-Cours PD 49
� Problème � ce motif est intéressant à utiliser lorsque l’algorithme de création
d’un objet complexe doit être indépendant des constituants de l’objet et de leurs relations, ou lorsque différentes représentations de l’objet construit doivent être possibles
� • Conséquences � + Variation possible de la représentation interne d’un produit
� l’implémentation des produits et de leurs composants est cachée au Director � Ainsi la construction d’un autre objet revient à définir un nouveau Builder
� + Isolation du code de construction et du code de représentation du reste de l’application
� + Meilleur contrôle du processus de construction
Hafidi Imad-ENSAK-Cours PD 50
Hafidi Imad-ENSAK-Cours PD 51
Hafidi Imad-ENSAK-Cours PD 52
Prototype
Hafidi Imad-ENSAK-Cours PD 53
� Problème � Le système doit être indépendant de la manière dont ses
produits sont créés, composés et représentés : les classes à instancier sont spécifiées au moment de l’exécution
� La présence de hiérarchies de Factory similaires aux hiérarchies de produits doivent être évitées. Les combinaisons d’instances sont en nombre limité
� Conséquences � mêmes conséquences que Factory et Builder
� • Exemple � java.lang.Cloneable
Hafidi Imad-ENSAK-Cours PD 54
Bilan ; Labyrinthe
Hafidi Imad-ENSAK-Cours PD 55
� Abstract Factory : CreateMaze a un objet en paramètre utilisé pour créer les composants du labyrinthe, on peut changer les composants de la structure du labyrinthe en passant un autre paramètre
� Builder : CreateMaze a un objet paramètre capable de créer lui même un labyrinthe dans sa totalité, il est possible de changer la structure du labyrinthe en dérivant un nouvel objet
� Factory: CreateMaze appelle des fonctions virtuelles au lieu de constructeurs pour créer les composants du labyrinthe, il est alors possible de modifier la création en dérivant une nouvelle classe et en redéfinissant ces fonctions virtuelles
� Prototype : CreateMaze est paramétré par des composants prototypiques qu’il copie et ajoute au labyrinthe, il est possible de changer la structure du labyrinthe en fournissant d’autres composants
Résumé
Hafidi Imad-ENSAK-Cours PD 56
� Le Factory Pattern est utilisé pour choisir et retourner une instance d ’une classe parmi un nombre de classes similaires selon une donnée fournie à la factory
� Le Abstract Factory Pattern est utilisé pour retourner un groupe de classes
� Le Builder Pattern assemble un nombre d’objets pour construire un nouvel objet, à partir des données qui lui sont présentées. Fréquemment le choix des objets à assembler est réalisé par le biais d’une Factory
� Le Prototype Pattern copie ou clone une classe existante plutôt que de créer une nouvelle instance lorsque cette opération est coûteuse
� Le Singleton Pattern est un pattern qui assure qu’il n’y a qu’une et une seule instance d’un objet et qu’il est possible d’avoir un accès global cette instance
Hafidi Imad-ENSAK-Cours PD 57
Designs Pattern de structure
Design Pattern de structure
Hafidi Imad-ENSAK-Cours PD 58
� Abstraction de la manière dont les classes et les objets sont composés pour former des structures plus importantes.
� Deux types de motifs : � Motifs de structure de classes
� Utilisation de l’héritage pour composer des interfaces et/ou des implémentations (ex : Adapter).
� Motifs de structure d’objets � composition d’objets pour réaliser de nouvelles fonctionnalités :
� ajouter d’un niveau d’indirection pour accéder à un objet ex : Adapter d’objet, Bridge, Facade, Proxy,
� composition récursive pour organiser un nombre quelconque d’objets ex : CompositeDesign
Adapter
Hafidi Imad-ENSAK-Cours PD 59
� Problème � Utilisation d’une classe existante dont l’interface ne nous convient
pas (convertir l’interface d’une classe en une autre) � Utilisation de plusieurs sous-classes dont l’adaptation des interfaces
est impossible par dérivation (Object Adapter) � Conséquences
� – Adapter de classe � + il n’introduit qu’une nouvelle classe, une indirection vers la classe adaptée
n’est pas nécessaire � MAIS il ne fonctionnera pas dans le cas où la classe adaptée est racine d’une
dérivation � – Adapter d’objet
� + il peut fonctionner avec plusieurs classes adaptées � MAIS il peut difficilement redéfinir des comportements de la classe adaptée
Hafidi Imad-ENSAK-Cours PD 60
Hafidi Imad-ENSAK-Cours PD 61
Bridge
Hafidi Imad-ENSAK-Cours PD 62
� Problème � ce motif est à utiliser lorsque l’on veut découpler
l’implémentation de l’abstraction de telle sorte que les deux puissent varier indépendamment
� • Conséquences � + interfaces et implémentations peuvent être couplées/
découplées lors de l’exécution
Hafidi Imad-ENSAK-Cours PD 63
Composite
Hafidi Imad-ENSAK-Cours PD 64
� Problème � établir des structures arborescentes entre des objets et les traiter
uniformément � • 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
Hafidi Imad-ENSAK-Cours PD 65
Exercice : composite
Hafidi Imad-ENSAK-Cours PD 66
� Chacun des membres de la compagnie reçoit un salaire. � A tout moment, il doit être possible de demander le coût d’un
employé. � Le coût d’un employé est calculé par :
� Le coût d’un individu est son salaire. � Le coût d’un responsable est son salaire plus celui de ses subordonnés.
Façade
Hafidi Imad-ENSAK-Cours PD 67
� Problème � ce motif est à utiliser pour faciliter l’accès à un grand nombre
de modules en fournissant une couche interface
� Conséquences � + facilite l’utilisation de sous-systèmes � + favorise un couplage faible entre des classes et l’application � – MAIS des fonctionnalités des classes interfacées peuvent être
perdues selon la manière dont est réalisée la Façade
Hafidi Imad-ENSAK-Cours PD 68
Proxy
Hafidi Imad-ENSAK-Cours PD 69
Hafidi Imad-ENSAK-Cours PD 70
� Problème � ce motif est à utiliser pour agir par procuration pour un objet
afin de contrôler les opérations qui lui sont appliquées � Masquer des problèmes d’accès (ex : fichier) � Différer l’exécution d’opérations coûteuses � Contrôler les droits d’accès
� Conséquences � + ajout d’un niveau d’indirection lors de l’accès d’un objet
permettant de cacher le fait que l’objet est dans un autre espace d’adressage, n’est pas créé, …
Hafidi Imad-ENSAK-Cours PD 71
Hafidi Imad-ENSAK-Cours PD 72
Designs Pattern de comportement
Design Pattern de comportement
Hafidi Imad-ENSAK-Cours PD 73
� Description de structures d’objets ou de classes avec leurs interactions
� Deux types de motifs � Motifs de comportement de classes :
� utilisation de l’héritage pour répartir les comportements entre des classes (ex : Interpreter)
� Motifs de comportement d’objets avec l’utilisation de l’association entre objets : � pour décrire comment des groupes d’objets coopèrent (ex : Mediator) � pour définir et maintenir des dépendances entre objets (ex : Observer) � pour encapsuler un comportement dans un objet et déléguer les requêtes à
d’autres objets (ex : Strategy, State, Command) � pour parcourir des structures en appliquant des comportements (ex : Visitor,
Iterator)
Command
Hafidi Imad-ENSAK-Cours PD 74
� Problème � on veut effectuer des requêtes sur des objets sans avoir à
connaître leur structure
� Conséquences � + découplage entre l’objet qui appelle et celui qui exécute � + l’ajout de nouvelles commandes est aisée dans la mesure où la
modification de classes existantes n’est pas nécessaire
Hafidi Imad-ENSAK-Cours PD 75
Hafidi Imad-ENSAK-Cours PD 76
Iterator
Hafidi Imad-ENSAK-Cours PD 77
� Problème � ce motif est à utiliser pour parcourir une collection d’éléments
sans accéder à sa structure interne
� Conséquences � + des variations dans le parcours d’une collection sont
possibles, � + simplification de l’interface de la collection � + plusieurs parcours simultanés de la collection sont possibles
Hafidi Imad-ENSAK-Cours PD 78
Momento
Hafidi Imad-ENSAK-Cours PD 79
� Problème � on veut sauvegarder l’état ou une partie de l’état d’un objet
sans violer le principe d’encapsulation
� Conséquences � + garder les limites de l’encapsulation � – peut-être coûteux en mémoire et en exécution
Hafidi Imad-ENSAK-Cours PD 80
Hafidi Imad-ENSAK-Cours PD 81
Hafidi Imad-ENSAK-Cours PD 82
Observer
Hafidi Imad-ENSAK-Cours PD 83
� Problème � on veut assurer la cohérence entre des classes coopérant entre
elles tout en maintenant leur indépendance � Conséquences
� + couplage abstrait entre un sujet et un observeur, support pour la communication par diffusion,
� – MAIS des mises à jour inattendues peuvent survenir, avec des coûts importants.
� • Exemple � java.util.Observable � java.util.Observer
Hafidi Imad-ENSAK-Cours PD 84
Hafidi Imad-ENSAK-Cours PD 85
State
Hafidi Imad-ENSAK-Cours PD 86
� Problème � ce motif est à utiliser lorsque l’on veut qu’un objet change de
comportement lorsque son état interne change
� • Conséquences � possibilité d’ajouter ou de retirer des états et des transitions de
manière simple � suppression de traitements conditionnels � les transitions entre états sont rendues explicites
Hafidi Imad-ENSAK-Cours PD 87
Strategy
Hafidi Imad-ENSAK-Cours PD 88
� Problème � on veut :
� définir une famille d’algorithmes, � encapsuler chacun et les rendre interchangeables tout en assurant que
chaque algorithme peut évoluer indépendamment des clients qui l’utilisent
� • Conséquences � + Expression hiérarchique de familles d’algorithmes, élimination de
tests pour sélectionner le bon algorithme, laisse un choix d’implémentation et une sélection dynamique de l’algorithme
� – Les clients doivent faire attention à la stratégie, surcoût lié à la communication entre Strategy et Context, augmentation du nombre d’objets
Hafidi Imad-ENSAK-Cours PD 89
Visitor
Hafidi Imad-ENSAK-Cours PD 90
� Problème � Des opérations doivent être réalisées dans une structure
d’objets comportant des objets avec des interfaces différentes � Plusieurs opérations distinctes doivent être réalisées sur des
objets d’une structure � La classe définissant la structure change rarement mais de
nouvelles opérations doivent pouvoir être définies souvent sur cette structure
� • Conséquences � + l’ajout de nouvelles opérations est aisé � + union de différentes opérations et séparations d’autres � – MAIS l’ajout de nouvelles classes concrètes est freinée
Hafidi Imad-ENSAK-Cours PD 91
Hafidi Imad-ENSAK-Cours PD 92