INTRODUCTION A DESIGN P - efreidoc.frefreidoc.fr/L2 -...

Intro Design Patterns -2007-2008

1

INTRODUCTION AUXDESIGN PATTERNS

Modèles de conception réutilisables

D’après le catalogue d’Erich Gamma, Richard Helm, Ralph

Johnson et John Vlissides (1995).


2

Pré requis• Bases de la conception OO.• Notation UML

– Diagrammes de classes– Diagrammes d’objets– Diagrammes de séquence

• Connaissance d’un langage OO (C++, Java, …).• Expérience significative de Programmation OO.

• NB : dans ce support, les diagrammes de classes présentés sont les originaux de Gamma et al., écrits en OMT. La notation d’OMT est dans ce cas très proche d’UML ; en cours/TD nous adapterons aisément en UML.


3

Plan du Cours

1. Rappels de POO et d’UML.2. Conception et réutilisation.3. Design Patterns généraux (23, Erich

Gamma et al.).

Rq : On peut trouver par ailleurs des DP concernant des domaines spécifiques comme la programmation parallèle ou distribuée, le temps réel, les IHM, BDD OO, réseaux, les graphes mathématiques, ...


4

I - Rappels de Programmation Orientée Objet et d’UML


5

Rappels de termes de POO• Classe : description d’un modèle d’objets semblables.• Objet : instance d’une classe (création d’un objet =

instanciation)• Classe abstraite : ne peut pas être instanciée

directement (dérivée en classes concrètes pour instanciations).

• Attribut : élément d’information constitutif des objets d’une classe.

• Méthode (fct° membre en C++) : élément de comportement constitutif des objets d’une classe ; réalise une opération.


6

Rappels de termes de POO• Encapsulation : principe permettant de cacher les

éléments constitutifs des objets.• Spécialisation/Généralisation (héritage) :

classification (passage d’une classe plus générale à une classe plus spécifique) et inversement ; hiérarchisation des classes.

• Association : relation entre classes ; décrit un ensemble de liens entre objets.

• Conception [objet] : étape consistant à produire une modélisation de l’application à réaliser.


7

Rappels de notation UML

• Unified Modeling Language.• Synthèse de : OOSE/Use case

(Jacobson), OMT (Rumbaugh), Booch, Harel (états-transitions), Shlaer et Mellor(cycle de vie).

• Adopté par l’OMG en 1997.• UML 2 …


8

UML• Langage de modélisation standard.• Très largement utilisé. • Permet d’aller au delà des modèles simplement

structurels Entités/Relations.• Permet de documenter les travaux.• Très bon outil de communication des travaux (spéc.

fonctionnelles, dossier de conception, …).

• Les Design Patterns sont des composants logiques décrits indépendamment d’un langage donné (dans 1 langage semi formel) => OMT, UML, …


9

Les 9 diagrammes d’UML

Réalisation du diagramme de classes à l’aide du plugin Omondo UML pour Eclipse.


10

Diagramme de classes

• Exprime la structure statique du système.

• Classes + relations entre les classes.• Interfaces, paquetages + leurs relations.


11

La classe

Nom de classe Nom de classe Nom de classe

Attributs

Méthodes

Exceptions

NomPaquetage1::NomPaquetage2::Nom de classe

<<stéréotype>>

Nom de classeEx : <<signal>>, <<exception>>, <<thread>> ; <<utilitaire>>


12

La classe

Bâtiment- adresse

# listePropriétaires

+ ajouterPropriétaire

+ enleverPropriétaire

- obtenirListe

. . .

+ BâtimentNonTerminé Exceptions

Méthodes/opérations

Attributs

Nom de la classe

Niveau de visibilité Classe abstraite (italique)

Classe de tous les types de constructions habitées.

Étiquette de commentaire


13

Interface

• Décrit le comportement visible d’une classe, composant, sous-sytème, paquetage (et uniquement cela).

• = Méthodes « public » (+).• Ni attribut ni association précisé.• Rq : « interface » en Java ; en C++, pas

de mot-clé.


14

Interface

Nom de classe

<<interface>>

Nom interfaceNom de classe

ouUtilisateur ( classe, …)

« Réalise »

« Utilise »

Cf. en Jave : « implements » pour réaliser et « import » pour utiliser.


15

AssociationNoms

Cardinalités


16

Agrégation, composition, généralisation

• Agrégation– Association non symétrique : 1 extrémité joue 1 rôle + important

(losange blanc).

• Composition– Cas particulier d’agrégation avec un couplage + fort (losange

noir).

• Généralisation/Héritage– Relation de classification entre un élément + général et un

élément + spécifique (triangle).


17

Exemple


18

Diagramme d’objets

• Diagramme d’objets ≡ diagramme d’instances.

• Instance d’un diagramme de classes.• Montre les objets et leurs liens.• Présente une structure statique.• Pour montrer un contexte, un exemple de

SDD complexe, etc.


19

Exemple


20

Diagramme de séquence• Interactions entre objets.• Représentation se concentrant sur la séquence

des opérations selon point de vue temporel.• Modélise les aspects dynamiques des systèmes

Temps Réel et scénarios complexes avec peu d’objets.

• Ne rend pas compte du contexte des objets de manière explicite.

• Sert notamment à documenter les cas d’utilisation (qui sont essentiels en analyse).


21

Notation


22

Exemple


23


24

II - Conception et de réutilisation


25

Qu’est-ce qu’un modèle (pattern) de conception ?

• Domaine de l’Architecture (bâtiments et villes) : Christopher Alexander (253 modèles de conception, 1977)– Chaque modèle décrit un problème qui se produit très

fréquemment dans notre environnement et l’architecture de la solution à ce problème.

– C. Alexander déclare que l’on peut concevoir une maison simplement par application successive de ses modèles l’un après l’autre.

– Description : nom, quoi, pourquoi, quand, comment, modèles en relation

• Hydraulique


26

Exemple de modèle d’AlexanderNom : Transition d’entrée. Quoi : Créer une transition du monde extérieur vers un

univers intérieur, plus privé. Pourquoi : L’entrée dans un bâtiment influence la façon dont

on va se sentir à l’intérieur. Quand : Systèmes d’accès et d’entrée pour les maisons, les

cliniques, les magasins, etc. Comment : Créer un espace de transition entre la rue et la

porte d’entrée. Marquer le cheminement dans l’espace de transition par un changement de lumière, un changement de direction, etc.

Patterns en relation : vue Zen (#134), ...

tiré de «Introduction aux patterns» Jean Bézivin


27

Domaine Informatique : Modèle de conception dans MVC de Smalltalk

• Classes Model/View/Controller (MVC) utilisé pour construire des IHM en Smalltalk-80.

• Modèle = l’objet application.• Vue = représentation visuelle de données.• Contrôleur = définit le comportement de l’IHM

aux introductions de données.• Séparation des vues et modèles + protocole de

communication par souscription et notification.• Avant MVC : l’IHM était 1 simple agrégat

d’objets.


28

MVC

• Rq : ce concept est généralisé dans le Design Pattern Observateur.

3 Vues

Modèle

Contrôleur non représenté ici


29

Modèle de conception

• Documenter puis réutiliser un savoir-faire en conception ayant fait ses preuves.

• Identifier, spécifier des abstractions d’un niveau supérieur aux classes, instances.

• Moyen de documenter les logiciels.• Aider à la construction de logiciels répondant à

des propriétés précises, de logiciels complexes.• Abstraits, ils doivent être implémentés pour les

utiliser.


30

Réutilisation de code source : Boite à outils/Librairie/Bibliothèque de classes

• Ensemble de classes (code source)– Apparentées mais pour la plupart indépendantes,– conçues pour offrir des fonctionnalités d’intérêt général,– réutilisables, – elles évitent au développeur de coder des fonctionnalités

d’usage très répandu.• Ex : bibliothèque de gestion des flux d’E/S C++ iostream,

collections et structures de données (STL en C++), lib. mathématiques …

• L’application utilisatrice importe la/les librairie(s).• N’impose à l’application utilisatrice aucune contrainte de

conception.• Généralement plus complexe à développer qu’une

application (quelles applis ? Quel besoins particuliers ?).


31

Réutilisation de conception : Framework

• Un framework est un squelette d’application d’un domaine particulier, composé d’un ensemble de classes qui coopèrent.

• Impose une certaine architecture une application (contraint et ainsi guide le développement).

• Toutes les applications développées sur la base d’un framework donné ont par conséquent des structures semblables (réutilisation de conception vs réutilisation de code).

• L’adaptation de certaines classes du frameworkà des besoins particuliers peut être effectuée par le développeur à l’aide de l’héritage.


32

Techniques courantes pour la réutilisation

1. Héritage2. Composition d’objets3. Types paramétrés dits « génériques » en Ada, Effeil ou

templates en C++

Conseils :• Programmer une interface plutôt qu’une implémentation.• Utiliser des classes abstraites en C++, interfaces en Java pour

définir des interfaces communes à un ensemble de classes.• Déclarer les variables et paramètres comme des instances de la

classe abstraite plutôt que comme instances de classes particulières. – Conséquence : les classes clientes et les objets sont indépendants des

classes qui implémentent l’interface.


33

Comparaison entre héritage et composition

• Héritage– Défini de manière statique à la compilation.– Permet de modifier facilement le code réutilisé.– Pendant l’exécution, il n’est pas possible de modifier le code

hérité d’un parent.– Une classe parente définit souvent une partie de la

représentation physique des futures sous-classes (=> rompt l’encapsulation ; lie le code de la sous-classe à celui de la classe parente)

– Si un caractère quelconque hérité ne convient pas à la sous-classe, il faut re-écrire la classe parente.

– Peut mener à la multiplication inutile de sous-classes. – Finalement : peu souple (l’idéal est de n’hériter que de classes

abstraites car peu ou pas de code).


34

Comparaison entre héritage et composition

• Composition– La composition d’objets est définie dynamiquement, à

l’exécution.– Chaque objet composant peut être remplacé par un autre.– Utilisation de la délégation (le récepteur délègue à son délégué

qui est un composant)– Donc un peu plus lent à l’exécution mais plus souple.– Multiplication des objets vs multiplication des classes (dév. +

léger)

• NB : Toujours se méfier de l’héritage : il est très souvent préférable d’utiliser la composition d’objets.


35

III - Design Patterns généraux (Erich Gamma et al.).


36

Comment présenter chaque modèle de conception

• Un nom : utile pour l’identifier, communiquer, documenter, faire de l’abstraction.

• Le problème : expose le sujet à traiter, la situation et conditions pour qu’il puisse être appliqué.

• La solution : décrit les éléments qui constituent la conception, leurs relations et coopérations.

• Les conséquences : implications de la mise en œuvre de la solution (avantages / inconvénients) en terme de mémoire, vitesse exécution, portabilité, extensibilité, etc.


37

Classement des modèles : 3 groupes

Modèles Créateurs• Expriment le principe du processus d’instanciation.• Pour rendre les systèmes indépendants de la façon dont les objets

sont créés. Modèles Structuraux• Etudient la manière de composer classes et objets pour réaliser des

structures plus importantes.• Utiles notamment pour permettre à des bibliothèques de classes

développées séparément de coopérer.• Permettre des connections indépendantes des évolutions futures de

l’application : découpler l’interface des implémentations.Modèles de comportement• Traitent des comportements/algorithmes et de l’affectation des

responsabilités entre objets. • Gestion des interactions dynamiques entre des classes et des

objets.


38

Classement des modèles


39

Modèles créateurs• Fabrique abstraite (Abstract Factory) : interface pour

la création de familles d’objets sans spécifier de classe concrète.

• Monteur (Builder) : séparation de la construction d’objets complexes des parties qui les composent afin qu’un même processus de construction puisse créer différentes représentations.

• Fabrication (Factory Method) : définit une interface pour la création d’objets en laissant le choix à des sous-classes les choix des classes à instancier.

• Prototype : spécification des types d’objet à créer à partir d’un objet prototype et crée les nouveaux objets en copiant le prototype.

• Singleton : assure l’unicité de l’instance d’une classe.


40

Modèles structuraux• Adaptateur (Adapter) : adapte/traduit l’interface d’une classe en

une autre interface qui correspond aux attentes du client.• Pont (Bridge) : découple une abstraction de son implémentation

afin que les deux puissent être modifiés indépendamment l’un de l’autre.

• Composite : structure pour la construction d’agrégations récursives.

• Decorateur (Decorator) : attache dynamiquement des responsabilités supplémentaires à un objet ; alternative à l’héritage.

• Facade : fournit une interface unifiée à l’ensemble des interfaces d’un sous-système ; simplifie l’utilisation du sous-système.

• Poids mouche (Flyweight) : utilise une technique de partage quand un de nombreux objets de fine granularité sont à mettre en œuvre.

• Procuration (Proxy) : fournit un mandataire pour contrôler l’accès à un objet.


41

Modèles de comportement• Chaîne de responsabilités (Chain of Responsibility) :

délègue des requêtes à des responsables de services ; évite couplage émetteur-récepteur.

• Commande : encapsule une requête par un objet ; permet notamment la réversion des opérations (Undo).

• Interprète : étant donné un langage, définit une représentation de sa grammaire.

• Itérateur : permet le parcours séquentiel des collections.• Médiateur : encapsule les modalités d’interaction d’un

ensemble d’objets ; favorise le couplage faible ; schéma en étoile.

• Mémento : capture et restauration de l’état d’un objet.


42

Modèles de comportement• Observateur : mise à jour automatique des objets

dépendants d’un objet.• Etat : permettre à un objet de modifier son

comportement lorsque son état interne change, comme s’il changeait de classe.

• Stratégie : abstraction pour sélectionner un algorithme parmi plusieurs disponibles.

• Patron de méthode (Template method) : dans une opération, définit le squelette d’un algorithme dont certaines étapes sont fournies par des sous-classes.

• Visiteur : représente une opération à effectuer sur les éléments d’une structure d’objet ; permet de définir une nouvelle opération sans modifier les classes des éléments sur lesquels il opère.


43

Relations entre les modèles de conception


44

1 - DP Singleton (créateur)• Intention

– Garantit qu’une classe n’a qu’une seule instance et fournit un point d’accès de type global à cette classe

– Tous les utilisateurs de la classe utilisent la même instance.

• Principe– Définir une opération permettant au client d’obtenir l’unique

instance de la classe Singleton


45

DP Singleton

• Très simple, le DP singleton est largement utilisé pour accéder à des ressources système telles que le presse-papier (clipboard).

• Evite de polluer l’espace de nom global par des variables statiques.

• La mise en œuvre de ce pattern est à faire avec prudence si plusieurs threads (Cf. cours prog. parallèle) peuvent accéder à l’instance unique.


46

DP Singleton• En C++ : méthode de classe (fonction membre

static).• On peut adapter facilement le modèle pour

permettre la création d’un nombre voulu d’instances.

• Attention en C++ : une méthode static ne peut pas être virtuelle => pas de liaison dynamique possible en cas d’héritage.

• Classiquement, on masque le constructeur (le client ne peut alors qu’appeler la méthode statique).


47

Exercice

• Proposez une solution d’implémentation en C++ pour une classe Clipboardpermettant de stocker un texte et de l’obtenir (lire).


48

2 - DP Observateur (comportement)

• Intention – Définir une interdépendance de type 1 à plusieurs, telle

que lorsque un objet change d’état, tous les objets qui en dépendent en sont notifiés et automatiquement mis à jour.


49

Diagramme de classes

Le sujet est observé par 0 à n observateurs.


50

Diagramme de séquence• Exemple : 1 sujet + 2 observateurs

• Modèle ‘PUSH’ : le sujet envoie aux observateurs une info détaillée sur les modifs(suppose par conséquent que sujet sait ce qui les intéresse ou qu’il envoie toutes les modifs, via par ex. un objet).

• Modèle ‘PULL’ : le sujet notifie simplement puis les observateurs réclament les détails (GetState()). (plus souple mais peut être moins efficace).


51

Exercice

• Le système de surveillance– Une simulation avec un thermomètre relié à

des alarmes de plusieurs sortes et dont les températures de déclenchement sont paramétrables.

– Modèle de conception + Code source C++.


52

3 - DP Composite (structurel)• Intention

– Composer des objets en des structures arborescentes pour représenter des hiérarchies composant / composé et permettre au client de traiter de la même manière les éléments terminaux et composites.

• Principe– Une classe abstraite représente à la fois les éléments

primitifs et les éléments composites (containers).


53

DP Composite


54

DP Composite


55

4 - DP Pont (structurel ; syn. Bridge, Poignée/Corps, Handle-Body)

• Intention :– Découpler une abstraction de son implémentation afin

que chacun puisse être modifié indépendamment de l’autre.

• Quand une abstraction peut avoir différentes implémentations, une solution pour les lier = l’héritage.– 1 classe de base abstraite qui définit l’interface

commune ; les héritières concrètes l’implémente – Manque de souplesse : liaison immuable entre la

classe de base et chaque classe dérivée.


56

DP PontDeux hiérarchies de classes séparées :

1. Hiérarchie pour les interfaces/classes abstraites2. Hiérarchie pour les implémentations

Exemple :

ApplicationWindow


57

DP Pont

• Favorise le développement en couches• Dissimule les détails d’implémentation au client (*) tant que

partage d’objets « implémenteurs », éventuellement les mécanismes de comptage de références)


58

DP Pont• Choix de la classe d’implémentation :

– Si toutes les classes d’implémenteur sont connues par l’abstraction, on peut passer un paramètre au constructeur de l’abstraction. Ex : Collection abstraite : en fct° de la taille a priori, le constructeur crée une liste chainée ou une table de hachage (grandes tailles). Autre possibilité : une implémentation initiale qui change au-delà d’une taille atteinte.

– Autres possibilités : déléguer à un autre objet le choix de l’implémentation (délégation à une Fabrique Abstraite par ex.), lire un/des paramètres d’environnement.


59

5 - DP Commande (comportement)

• Intention – encapsuler une requête par un objet (permet

notamment la réversion des opérations).


60

DP Commande

• Ici le récepteur est l’application qui gère le document (le document n’existe pas avant d’exécuter la commande).


61

DP Commande

• Macro commandes : séquence de commandes simples ou macros.

• Undo : l’opération Execute() peut stocker un état dans l’objet commande pour le rétablir ; l’interface de Command doit posséder une opération supplémentaire : Undo().


62

Exercice• On suppose que l’on dispose des commandes

Filtre1, Filtre2, .. FiltreN implémentant le D.P. Command dans une application de traitement d’images.

• On veut écrire une classe de macro commandes de traitements d’images.

• Donnez le modèle de conception faisant intervenir les N filtres et la macro commande puis une implémentation minimale de cette dernière en C++.


63

6 - DP Procuration (structurel, Proxy, subrogé)

• Intention : fournir un mandataire/remplaçant pour contrôler l’accès à un objet.

• Motivation : différer ce qui est coûteux dans la création et l’initialisation d’un objet au moment du son utilisation effective.

• Ex. : doc traitement de texte avec images volumineuses ; simple encombrement de l’image ou bien affichage de l’image.


64

DP Procuration

Rq : pour une image de petite taille, il n’est pas forcément nécessaire d’utiliser un proxy (heuristique).


65

DP Procuration

• Indications d’utilisation : – procuration virtuelle (Cf. images),– procuration à distance (espace d’@ ≠), – procuration de protection, – pointeurs intelligents (Smart Pointers).


66

Exercice

• Pointeur intelligent : référence un objet exactement comme un pointeur, mais il n’est pas nécessaire de faire manuellement les destructions.

• Déclarer et implémenter l’interface minimale d’une classe C++ SmartPtrInt de pointeurs intelligents sur des entiers (int) ; on généraliserait sans difficulté en faisant un patron (template) de cette classe.


67

7 - DP Fabrique Abstraite (créateur, Kit)

• Intention : fournir une interface pour la création de familles d’objets sans spécifier de classe concrète.

• Ex : boite à outils pour IHM avec plusieurs look-and-feels.

• Code client indépendant du look-and-feel.


68

DP Fabrique Abstraite

• La classe abstraite WidgetFactory définit une interface (ici non exhaustive) pour créer chaque catégorie de widgets (= objets graphiques).


69

DP Fabrique Abstraite


70

DP Fabrique Abstraite• Souvent implémentation des fabriques

concrètes sous forme de DP Singletons. • Pour fabriquer de nombreuses sortes d’objets,

on peut implémenter la fabrique à l’aide du DP Prototype ; la fabrique crée un nouveau produit par clonage du prototype du produit. (la classe abstraite Prototype contient une méthode clone() qui retourne la copie de l’objet sur lequel elle est invoquée : le prototype se clone lui même).

• Les familles d’objets doivent donc dans ce cas être « clonable » (Cf. cours de Java)


71

8 - DP Etat (Comportement, alias « objets d’état »)

• Intention : permet à un objet de modifier son comportement lorsque son état interne change, comme s’il changeait de classe.

• Indication d’utilisation :– Le comportement d’un objet dépend de son état et

l’état change dynamiquement. – Les opérations de la classe comportent de grands

pans de déclarations conditionnelles fonctions de l’état de l’objet (if / else à éviter au maximum !) que l’on retrouve de plus souvent dans les différentes opérations.


72

DP Etat* Context : définit l’interface intéressant les clients et gère un objet état d’une des classes concrètes.

* State : définit une interface encapsulant le comportement associé à un état particulier du contexte.

* ConcreteStateX : Chaque sous-classe implémente le comportement d’un état des objets de classe Context


73

DP Etat – Application directe• Exercice : représenter un automate à états fini.

s0 s1 s2

‘g’

‘e’ ‘d’ ‘f’


74

DP Etat – Application directe

Automaton

Automaton()~Automaton()void setStartState(State * s)void start()void get_input(char c)void setCurrentState(State * s)

State

void next(char c)automaton

2current,start

S0

void next(char c)

S1

void next(char c)

S2

void next(char c)


75

DP Etat – Application directe• Les états initial et final seront représentés par un objet NULL.

Les transitions se font quand le caractère est reçu par l’automate (ex : l’automate dans l’état s0 passe à l’état s1 s’il reçoit le caractère ‘e’ mais il ne change pas d’état pour tout autre caractère).

• Quant l’automate est créé, il est sans état, les états initial et courant sont NULL ; setStartState() permet de renseigner l’état initial (s0) de l’automate ; start() positionne l’automate sur cet état ; get_input() permet à l’automate de recevoir un caractère (et donc parfois de changer d’état) ; setCurrentState() permet de changer l’état courant de l’automate. Dans les classes d’états, la méthode next() permet de changer d’état courant quand le caractère reçu est un caractère qui permet une transition.


76

9 - DP Stratégie (Comportement) (alias : Politique, Strategy, Policy)

• Intention : définit une famille d’algorithmes, encapsule chacun d’eux et les rend interchangeables. Cela permet aux algorithmes d’évoluer (être modifiés) indépendamment des clients utilisateurs.– Un algorithme encapsulé est dit « stratégie ».

• Indication : – plusieurs classes apparentées ne diffèrent que par leur

comportement,– On a besoin de plusieurs variantes d’un algorithme (différentes

optimisations selon vitesse / occup. Mémoire)– Un algo utilise des données que le client n’a pas à connaître

(évite de révéler les SDD spécifiques, internes des algos)– Une classe définit de nombreux comportement (if / else à éviter

!)


77

Stratégie* Strategy : déclare une interface commune à tous les algorithmes définis. Contexte utilise cette interface pour appeler l’algorithme défini par un objet ConcreteStrategyX.

* ConcreteStrategy : implémente un algo particulier.

* Contexte : fait référence à un objet stratégie concrète.


78

Stratégieclass Strategy {

public: virtual void runAlgorithm() = 0;};

class Context {private:

Strategy * strategy;public:

Context() { strategy = new ConcreteStrategyA(); }void changeStrategy(const Strategy & newS) {if (strategy) delete strategy ; strategy = new Strategy(newS); }void getResult() { strategy.runAlgorithm(); }

};

class ConcreteStrategyA : Strategy {public: void runAlgorithm() { // implém algo A }

};

class ConcreteStrategyB : Strategy {public: void runAlgorithm() { // implém algo B }

};

int main() {Context * context = new Context();context->getResult();concreteStrategyB sB;context->changeStrategy(sB);context->getResult();

}


79

Pont vs Stratégie

• On peut confondre à première vue les 2 patterns.

• Ils ont même structure, cependant ils permettent de résoudre des problèmes différents.

• La Stratégie traite de l’encapsulation d’algorithmes alors que le Pont découple l’abstraction de l’implémentation ce qui permet pour une même abstraction d’avoir plusieurs implémentations.


80

Autres Designs patterns : le DP « Marqueur »

• Intention : signaler qu’une classe possède une propriété particulière.

• Principe : le marqueur est une interface qui ne possède ni attribut ni méthode. Son seul intérêt est de signaler qu’une classe possède une caractéristique particulière.

• Dans la plateforme Java (Cf. cours Java), il est largement utilisé (ex : interface Serializable, Clonable, …).


81

Autres Designs patterns : le DP « Immuable »

• Intention : évite les effets de bord lors des changements d’états d’un objet et améliore les performances en cas d’accès concurrents

• Principe : – créer un objet qui ne peut pas changer d’état ; ce

dernier est fixé une fois pour toutes lors de l’instanciation de l’objet et ne peut plus être modifié.

– Si l’on souhaite effectuer une modification sur l’objet, il faut en faire une copie modifiée.

• En Java, utilisé par ex. pour la classe String.


82

Références• L’Indispensable « Design Patterns – Catalogue de

modèles de conception réutilisables », Erich Gamma et al., Editions Addison Wesley - Vuibert. (version originale en anglais) qui propose de nombreux articles « historiques ».

• Google !

INTRODUCTION A DESIGN P - efreidoc.frefreidoc.fr/L2 -...

Documents

Transcript of INTRODUCTION A DESIGN P - efreidoc.frefreidoc.fr/L2 -...