Patron de conception Composite

Slides:



Advertisements
Présentations similaires
La classe String Attention ce n’est pas un type de base. Il s'agit d'une classe défini dans l’API Java (Dans le package java.lang) String s="aaa"; // s.
Advertisements

Approfondissement du langage
Introduction à Java - les paquetages -
le langage les éléments
C.
Design Pattern MVC En PHP5.
Programmation par Objets et Java
1 ARCHITECTURE DACCÈS la méthode générale modèle de données définitions module daccès / modules métiers construction des modèles les modules daccès, les.
Page de garde Introduction aux Design Patterns ISIA, Mars 2003
Active Directory Windows 2003 Server
Programmation orientée objet
Contrôles d'accès aux données
XML-Family Web Services Description Language W.S.D.L.
Les méthodes en java Une méthode est un regroupement d’instructions ayant pour but de faire un traitement bien précis. Une méthode pour être utilisée.
Le Travail Collaboratif ...
Principes de programmation (suite)
© 2007 P. Van Roy. All rights reserved. FSAB1402: Informatique 2 Le Langage Java et les Exceptions Peter Van Roy Département dIngénierie Informatique,
77 Utilisation des classes (suite). 7-2 Objectifs A la fin de ce cours, vous serez capables de : Définir des méthodes surchargées dans une classe Fournir.
Chapitre 21 Collections Partie I Introduction Une collection : est un objet qui regroupe multiple éléments dans une unité. Une collection est.
Factory Design Patterns Factory Method
Les fichiers indexés (Les B-arbres)
Structures de données IFT-2000
Behavioral Design Patterns The Observer Pattern Roberto Demontis Sylvain Giroux.
P. Van Roy, LINF1251 LINF1251: Le Langage Java Peter Van Roy Département dIngénierie Informatique, UCL
Architecture dun site de vente au détail1 Modèle d'un site simple de vente Lexemple du livre Ruby on Rails Partie II Java Adventure Builder Demo Réalisé.
1 IFT 6800 Atelier en Technologies dinformation Le langage de programmation Java chapitre 3 : Classes et Objects.
Types de données abstrait et mécanismes d'encapsulation
Langages orientés objets
Chapitre 3 Les bibliothèques de balises JSP et la JSTL
Patrons de conceptions de créations
Structures de données IFT-2000 Abder Alikacem La récursivité Département d’informatique et de génie logiciel Édition Septembre 2009.
Interoperabilité des SI - Urbanisation
Héritage et composition
JEE 5 F.Pfister 2 institut eerie JEE – Une plateforme serveur  Développement et exécution d'applications réparties.
8 - XML Cours XML.
Travaux Pratiques Représentation des connaissances
Paradigmes des Langages de Programmation
JavaScript Nécessaire Web.
Content Management System CMS. Pourquoi ? Obligation de ressaisir des contenus publiés à plusieurs endroits Pas d’outils de gestion de qualité de l’information.
Domain Name System DNS. Le principe basé sur le modèle client / serveur le logiciel client interroge un serveur de nom; typiquement : –l’utilisateur associe.
Paradigmes des Langages de Programmation
La notion de type revisitée en POO
Factory Design Patterns. Contents Factory patterns: principesFactory patterns: principes The Factory Method patternThe Factory Method pattern The Abstract.
JDBC L'API JDBC est utilisée pour utilisée pour intéragir avec une base de données.
Design Patterns en programmation par objets. Plan  Design patterns –De quoi s’agit-il? –Pourquoi faut-il les utiliser?  Design patterns essentiels 
Designs Patterns comment rendre son code faiblement couplé, et maintenable...
Variables et accès en Java. Déclaration des variables final transient static private Printer hp; transient => ne doivent pas être sérialisées volatile.
Template Method Design Pattern. But Définir le squelette d’un algorithme tout en déléguant certaines étapes aux sous-classes. Les sous-classes peuvent.
Créer des packages.
CSI3525: Concepts des Langages de Programmation Notes # 13: Introduction au SmallTalk.
Master 1 SIGLIS Java Lecteur Stéphane Tallard Les erreurs communes en Java.
IFT 232 Méthodes de Conception Orientées Objets Introduction.
Arbres binaires et tables de hachage
© 2005 P. Van Roy. All rights reserved. FSAB1402: Informatique 2 Le Langage Java Peter Van Roy Département d’Ingénierie Informatique, UCL
Tutorat en bio-informatique
C++ L’HERITAGE Fayçal BRAÏKI DUT INFORMATIQUE.
Module 4 : Implémentation de l'intégrité des données.
Présentation du framework JSF (Java Server Faces) dans le modèle événementiel MVCII
IFT 232 Méthodes de Conception Orientées Objets Introduction.
Patron de conception Composite
Cours LCS N°4 Présenté par Mr: LALLALI
Struts.
Behavioral Design Patterns The Observer Pattern. Intention Définir une dépendance de “1” à “n” entre des objets de telle sorte que lorsque l’état d’un.
La programmation par objets Principes et concepts Etude de Smalltalk.
Cours 4 (14 octobre) Héritage. Chapitre III Héritage.
Hiver 2004SEG2501 Chapître 41 Chapître 4 SDL – structure d’un système et son comportement.
Factory Design Patterns Raffaella Sanna Sylvain Giroux.
Introduction à la Programmation Orientée Objet
INTRODUCTION AUX BASES DE DONNEES
Template Method Design Pattern. But Définir le squelette d’un algorithme tout en déléguant certaines étapes aux sous-classes. Les sous-classes peuvent.
Transcription de la présentation:

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 les objets individuels uniformément.

Motivation Les applications graphiques contiennent plusieurs sortes d’objets Pour regrouper les objets, on utilise des contenants (hiérarchie d’objets) qui demandent 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érarchies d’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 interagir avec 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 objet composite. 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 difficile l’application de contraintes sur les composantes d’un composite. Dans certains cas, on désire ne permettre que certains types de composantes dans un composite. Dans un composite, on ne peut pas utiliser le système de typage pour assurer cette contrainte. 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 dans la classe/interface Component. Les classes Leaf et Composite héritent de cette référence et des mé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 la classe 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 vers la racine Solution : Patron de conception “Flyweight” Explique comment retravailler le design pour éviter d’emmagasiner tous les parents 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 pas né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 classe Component La classe Component contient les déclarations des opérations d’accès et 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 peu feuilles 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 recherche d’information dans ses fils La classe Composite peut placer dans une cache des 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 est invalide.

DNS name servers * Figure 9.4 jeans-pc.dcs.qmw.ac.uk 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 .... Note: Name server names are in italics, and the corresponding domains are in parentheses. Arrows denote name server entries authoritative path to lookup: jeans-pc.dcs.qmw.ac.uk *

DNS in typical operation 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 .... Without caching IP: alpha.qmw.ac.uk 2 Animation: reveals each step in looking up jeans-pc.dcs.qmw.ac.uk from a client in the ic.ac.uk domain Discuss how caching reduces the number of steps. client.ic.ac.uk IP:jeans-pc.dcs.qmw.ac.uk 4 jeans-pc.dcs.qmw.ac.uk ? IP:ns0.ja.net 1 3 IP:dns0.dcs.qmw.ac.uk *

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 un Composite responsable de la destruction des fils lorsque celui-ci est détruit Une exception à cette règle survient lorsque les objets Leaf sont immuables et peuvent par 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 de structures 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 (comme toujours) 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 le patron Composite. Une expression RTL est une Component pour les arbres de dérivation. Elle possède des sous-classes, comme BinaryExpression, qui contiennent des fils de type RTLExpression. Ces classes définissent une structure composite pour les arbres de dérivation. RegisterTransfer est une classe Component pour la représentation des affectations 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 que le registre est utilisé après le retour de la routine Une autre sous-classe, RegisterTransferSet, est une classe composite pour représenter les affectations qui modifient plusieurs registres en même temps. Un autre exemple de l’utilisation de ce patron provient du domaine de la finance, 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é pour le 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, des opé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 les composites. Le patron de conception “Visitor” rend locaux les comportements et les opérations qui autrement seraient répartis à travers les classes Composite et Leaf.

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 Webpage from 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

Decorator Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending 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 object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles 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