7e ift232 design patterns composite

5/12/2018 7e IFT232 Design Patterns Composite - slidepdf.com

http://slidepdf.com/reader/full/7e-ift232-design-patterns-composite 1/31

Patron de conception Composite



Intention Organiser les objets en structures

arborescentes pour représenter des

hiérarchies tout-parties.

Les composites permettent aux client de

manipuler les objets composés et lesobjets individuels uniformément.



Motivation Les applications graphiques contiennent plusieurs sortes d’objets

Pour regrouper les objets, on utilise des contenants (hiérarchie d’objets) quidemandent la plupart du temps un traitement uniforme

Une classe abstraite (Graphic) représente à la fois les objets primitifs et leur contenant.

• Méthode draw

• Méthodes partagées par tous les objets composites : accès et gestion des fils



Quand appliquer le DP Composite?

Pour représenter des hiérarchiesd’objets tout-parties.

Pour permettre aux clients d’ignorer la

différence entre les objets composés et

les objets individuels.• Les clients vont pouvoir manipuler tous les

objets uniformément.



Structure



Participants

Component (Graphic)• Déclare l’interface des objets faisant partie du composite. • Implémente le comportement par défaut de l’interface partagée par toutes les classes

• Déclare une interface pour accéder et gérer les fils• Définit une interface pour accéder au père dans la structure récursive et l’implémente

le cas échéant. (optionel)

Leaf (Rectangle, Line, Text, etc.)• Représente les feuilles du composite.• Une feuille n’a pas de fils. • Définit le comportement des objets primitifs du composite.

Composite (Picture)

• Définit le comportement des composantes qui ont des fils.• Emmagasine les fils.• Implémente les méthodes liées aux fils de l’interface Component

Client • Manipule les objets du composite à travers l’interface Component



Collaborations

Les clients utilisent l’interface Component pour interagiravec les objets de la structure composite.

Si le destinataire est une feuille,alors la requête est effectuée directement.

Si le destinataire est un composite,

alors

généralement la requête est transmise aux fils

des opérations additionnelles peuvent aussi être faites

avant et/ou après la transmission aux fils



Conséquences - avantages

Définition d’une hiérarchie de classes formée d’objets primitifs et d’objets composites • Les objets primitifs peuvent être composés en objets plus complexes

• qui peuvent être composés en objets plus complexes• qui peuvent être…

• Lorsque le code du client s’attend à un objet primitif, il peut aussi recevoir un objetcomposite.

Simplifie le client.• Les clients peuvent manipuler les structures composites et les objets individuels

uniformément.• Les clients ne savent pas (et ne devraient pas se préoccuper de savoir) s’ils manipulent un

objet composite ou une feuille.• Cela simplifie le code du client en évitant les tests sur la classe des objets qui forment le

composite.

Facilite l’ajout de nouvelles sortes de composantes • Les nouvelles sous-classes de Composite ou Leaf fonctionnent automatiquement dans

les structures existantes et le code des clients.• Les clients ne doivent pas être modifiés pour tenir compte des nouvelles classes.



Conséquences - désavantages

Peut rendre le design trop général

• Le désavantage de faciliter l’ajout de nouvelles composantes est de rendre plus difficilel’application de contraintes sur les composantes d’un composite.

• Dans certains cas, on désire ne permettre que certains types de composantes dans uncomposite.

• Dans un composite, on ne peut pas utiliser le système de typage pour assurer cettecontrainte.

• Il faudra faire les tests à l’exécution.



Implémentation I

Référence explicite au père.

• Peut simplifier les parcours et la gestion d’une structure composite• (e.g. la suppression d’un noeud).

• Facilite l’implémentation du DP Chain of Responsibility.

• En général, la référence (variable d’instance) au père est définie dansla classe/interface Component.

• Les classes Leaf et Composite héritent de cette référence et desméthodes de gestion associées.

• Maintenir la cohérence des liens père-fils.• Ne permettre la modification de la variable d’instance que lors de l’ajout ou

la suppression de noeuds.

• L’implémenter une seule fois dans les méthodes add et remove de laclasse Composite.



Implémentation II

Partage de composantes

• Par exemple pour réduire les besoins en mémoire

• Difficile à gérer si une composante peut avoir plusieurs pères

• Peut mener à des ambiguités par exemple si une requête percole versla racine

• Solution : Patron de conception “Flyweight”

• Explique comment retravailler le design pour éviter d’emmagasiner tous lesparents ensemble dans le fils partagé

• Permet d’externaliser en tout ou en partie l’état du fils.



Implémentation III

Maximiser l’interface Component.

• Y définir le plus possible de méthodes communes• pour éviter de devoir tenir compte de la classe du noeud.

• Component• implémentations par défaut de ces méthodes

• Leaf• redéfinition de ces méthodes

• Par contre, toutes les opérations des noeuds intermédiaires ne sont pasnécessairement significatives pour les feuilles,

• Par exemple les feuilles ne peuvent pas avoir de fils.

• Comment Component peut-il spécifier une implémentation par défaut ?



Implémentation IV

Déclaration des méthodes de gestion des fils (add – remove).

• La classe Composite implémente les méthodes d’ajout et de retrait des fils.

• Par contre, qui doit déclarer ces méthodes ?• Dans l’interface commune Component ?

• il faudra les rendre significatives pour les feuilles

• Dans la classe Composite et ses sous-classes?

• Compromis entre la sécurité et la transparence

• Transparence

• déclaration à la racine de la hiérarchie, i.e. dans l’interface commune Component

•traitement uniforme des composantes

• au détriment de la sécurité car les clients peuvent invoquer des méthodes non significatives.

• Sécurité

• déclaration dans la classe Composite

toute tentative d’ajouter ou supprimer des fils à partir des feuilles sera détectée à la compilation au détriment de la transparence car les composites et feuilles auront des interfaces différentes

• Habituellement il est préférable de faire échouer add et remove par défaut

• par exemple en déclenchant une exception



Implémentation V

Est- ce que l’implémentation de Component utilise une liste de Components pour conserver les fils?

• Définir l’ensemble des fils comme une variable d’instance de la classeComponent

• La classe Component contient les déclarations des opérations d’accèset de gestion des fils.

• Placer un pointeur vers le fils dans la classe de base• pénalité : coût au niveau de l’espace-mémoire pour chaque feuille,

même si une feuille n’a jamais de fils

Cette approche est valable seulement s’il y a relativement peufeuilles dans la structure



Implémentation VI

Ordonnancement des fils.

• Lorsque l’ordre des fils est important,

il faut porter une attention particulière

au design des interfaces

(au niveau de l’ordre et de la gestion des accès aux fils)

afin de gérer correctement la séquence des fils

• Le patron de conception “Iterator” peut s’avérer fort utile àcette fin.



Implémentation VII

Utiliser des caches pour améliorer la performance

S’il est nécessaire de parcourir ou rechercher des composites fréquemment,

la classe Composite peut utiliser des caches du parcours ou de la recherched’information dans ses fils

La classe Composite peut placer dans une cachedes résultats courants ou simplement de l’information

qui permettent de court-circuiter le parcours ou la recherche.

• Une modification d’une composante exigera d’invalider les caches de ses parents

• Cette approche fonctionne le mieux lorsque les composantes connaissent leur parent

• Par conséquent si des caches sont utilisées,il faut définir une interface qui permette d’indiquer aux composites que leur cache estinvalide.



DNS name servers

Note : Name server names are initalics, and the correspondingdomains are in parentheses.Arrows denote name serverentries

a.root-servers.net (root)

ns0.ja.net (ac.uk)

dns0.dcs.qmw.ac.uk (dcs.qmw.ac.uk)

alpha.qmw.ac.uk (qmw.ac.uk)

dns0-doc.ic.ac.uk (ic.ac.uk)

ns.purdue.edu (purdue.edu)

uk purdue.edu

ic.ac.uk

qmw.ac.uk...

dcs.qmw.ac.uk

*.qmw.ac.uk *.ic.ac.uk *.dcs.qmw.ac.uk

* .purdue.edu

ns1.nic.uk (uk)

ac.uk...

co.uk

yahoo.com....

Figure 9.4

authoritative path to lookup:

jeans-pc.dcs.qmw.ac.uk

*



DNS in typical operationa.root-servers.net (root)

ns0.ja.net (ac.uk)

dns0.dcs.qmw.ac.uk (dcs.qmw.ac.uk)

alpha.qmw.ac.uk (qmw.ac.uk)

dns0-doc.ic.ac.uk (ic.ac.uk)

ns.purdue.edu (purdue.edu)

uk purdue.edu

ic.ac.uk

qmw.ac.uk...

dcs.qmw.ac.uk

*.qmw.ac.uk *.ic.ac.uk *.dcs.qmw.ac.uk

* .purdue.edu

ns1.nic.uk (uk)

ac.uk

...

co.uk

yahoo.com....

client.ic.ac.uk

IP: alpha.qmw.ac.uk

2

3IP:dns0.dcs.qmw.ac.uk

jeans-pc.dcs.qmw.ac.uk ?

IP:ns0.ja.net

1

IP:jeans-pc.dcs.qmw.ac.uk

4

Without caching

*



Implémentation VIII

Qui devrait détruire les composantes?

• Dans les langages sans ramasse-miettes, il

est en général préférable de rendre unComposite responsable de la destructiondes fils lorsque celui-ci est détruit

• Une exception à cette règle survient lorsqueles objets Leaf sont immuables et peuventpar conséquent être partagés.



Implémentation IX

Quelle est la structure de données la plus appropriée pour emmagasiner les composantes?

Les composites peuvent utiliser un grand choix destructures de données pour emmagasiner les fils :listes chaînées, arbres, vecteurs, tables de hachage(hash tables), etc.

Le choix de la structure de données dépend (commetoujours) de l’efficacité.



Utilisations

La classe View du Model/View/Controller de Smalltalk était un Composite,

Le framework de compilation de RTL Smalltalk utilisait abondamment lepatron Composite.• Une expression RTL est une Component pour les arbres de dérivation. Elle

possède des sous-classes, comme BinaryExpression, qui contiennent desfils de type RTLExpression. Ces classes définissent une structure compositepour les arbres de dérivation.

• RegisterTransfer est une classe Component pour la représentation desaffectations de la forme Single Static Assignment (SSA) tel que

• Affectation primitive qui effectue une opération sur deux registres et affecte le résultatà un troisième.

• Affectation avec un registre source mais sans registre destination, ce qui siginifie quele registre est utilisé après le retour de la routine

• Une autre sous-classe, RegisterTransferSet, est une classe composite pourreprésenter les affectations qui modifient plusieurs registres en même temps.

Un autre exemple de l’utilisation de ce patron provient du domaine de lafinance, un portfolio est un aggrégat de biens individuels.• Le portfolio est implémenté en tant que composantes respectant l’interface des biens

individuels.



Patrons de conception reliés

Dans plusieurs cas, le lien entre une composante et son parent est utilisé pourle patron de conception “Chain of Responsibility”.

Le patron de conception “Decorator” est souvent utilisé avec le patron“Composite”.• Lorsque les décorateurs et les composites sont utilisés ensemble, ils possèdent

habituellement une superclasse commune.

• Ainsi les décorateurs devront supporter l’interface Component et, partant, desopérations comme add , remove, et getChild .

Le patron de conception “Flyweight” permet de partager les composantes,• par contre ces dernières ne peuvent plus posséder de références sur leurs pères

(alors multiples).

Le patron de conception “Iterator” peut être utilisé pour parcourir lescomposites.

Le patron de conception “Visitor” rend locaux les comportements et lesopérations qui autrement seraient répartis à travers les classes Composite etLeaf.



Références

Gamma et al., Design Patterns

The Composite pattern and Struts Tiles

• The Apache Struts framework includes a JSP tag library, known as Tiles, that lets you compose a Webpagefrom multiple JSPs.

• Tiles is actually an implementation of the J2EE (Java 2 Platform, Enterprise Edition) CompositeView pattern,itself based on the Design Patterns Composite pattern.

Java Design Patterns • http://www.javaworld.com/columns/jw-java-design-patterns-index.shtml

• A look at the Composite design pattern• Treat primitive and composite objects the same way

• http://www.javaworld.com/javaworld/jw-09-2002/jw-0913-designpatterns-p2.html

• Web application components made easy with Composite View• Implement Web applications featuring pluggable components with the Composite View

design pattern• http://www.javaworld.com/javaworld/jw-12-2001/jw-1228-jsptemplate.html

http://www.javaworld.com/columns/jw-java-design-patterns-index.shtml

http://www.javaworld.com/javaworld/jw-09-2002/jw-0913-designpatterns-p2.html

http://www.javaworld.com/javaworld/jw-12-2001/jw-1228-jsptemplate.html
































Decorator

Attach additional responsibilities to an object dynamically.

Decorators provide a flexible alternative to subclassing forextending functionality.



Decorator - exemple



Flyweight

Use sharing to support large numbers of fine-grained objects efficiently.



Flyweight - exemple



Chain of responsibility

Avoid coupling the sender of a request to its receiver by giving more than one objecta chance to handle the request.

Chain the receiving objects and pass the request along the chain until an objecthandles it.



Chain of responsibility - exemple



Visitor

Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it

operates.



Visitor - exemple

7e ift232 design patterns composite

Documents