Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

Similar documents
The Composite Design Pattern

Design Pattern: Composite

Object-Oriented Oriented Programming

Tecniche di Progettazione: Design Patterns

Produced by. Design Patterns. MSc in Computer Science. Eamonn de Leastar

Design Patterns. Vasileios Theodorou

The Composite Pattern

Think of drawing/diagramming editors. ECE450 Software Engineering II. The problem. The Composite pattern

CISC 322 Software Architecture

COSC 3351 Software Design. Design Patterns Structural Patterns (I)

Last Lecture. Lecture 17: Design Patterns (part 2) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 4448/ Spring Semester, 2005

Introduction and History

Tecniche di Progettazione: Design Patterns

Design Patterns IV Structural Design Patterns, 1

Tecniche di Progettazione: Design Patterns

Design Patterns IV. Alexei Khorev. 1 Structural Patterns. Structural Patterns. 2 Adapter Design Patterns IV. Alexei Khorev. Structural Patterns

Considerations. New components can easily be added to a design.

Design Patterns. Comp2110 Software Design. Department of Computer Science Australian National University. Second Semester

Design Patterns. Decorator. Oliver Haase

Design Patterns. Definition of a Design Pattern

Last Lecture. Lecture 26: Design Patterns (part 2) State. Goals of Lecture. Design Patterns

Design Patterns. Comp2110 Software Design. Department of Computer Science Australian National University. Second Semester

SDC Design patterns GoF

Design Patterns (Composite)

Topics in Object-Oriented Design Patterns

Design Patterns in C++

Outline. Composite Pattern. Model-View-Controller Pattern Callback Pattern

Composite Pattern. IV.4 Structural Pattern

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

2.1 Design Patterns and Architecture (continued)

Software Eningeering. Lecture 9 Design Patterns 2

Design Patterns Lecture 2

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

6.3 Patterns. Definition: Design Patterns

Object Design II: Design Patterns

2.1 Design Patterns and Architecture (continued)

CS 2340 Objects and Design

Design Patterns (Facade, Composite)

Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

Details of Class Definition

EMBEDDED SYSTEMS PROGRAMMING Design Patterns

Software Engineering Design & Construction

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

EMBEDDED SYSTEMS PROGRAMMING Design Patterns

Design Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011

THOMAS LATOZA SWE 621 FALL 2018 DESIGN PATTERNS

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

The Observer Design Pattern

Enforcing Singularity

Laboratorio di Sistemi Software Design Patterns 2

» Access elements of a container sequentially without exposing the underlying representation

CSE 431S Type Checking. Washington University Spring 2013

Motivating Problem (2) Design for tree structures with whole-part hierarchies. The Composite Design Pattern

administrivia today UML start design patterns Tuesday, September 28, 2010

Event Dispatch. Dispatching events to windows and widgets.

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

Design of Software Systems (Ontwerp van SoftwareSystemen) Design Patterns Reference. Roel Wuyts

Design patterns. Valentina Presutti courtesy of Paolo Ciancarini

CSCI 253. Overview. The Elements of a Design Pattern. George Blankenship 1. Object Oriented Design: Iterator Pattern George Blankenship

Software Engineering Design & Construction

Alternator. An Object Behavioral Design Pattern. John Liebenau

Adapter pattern. Acknowledgement: Freeman & Freeman

What is a Pattern? Lecture 40: Design Patterns. Elements of Design Patterns. What are design patterns?

Design Pattern and Software Architecture: IV. Design Pattern


Design Patterns. An introduction

Software Quality Management

Keywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator.

Design patterns. OOD Lecture 6

Design Patterns (Composite, Iterator)

Information systems modelling UML and service description languages

Trusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

Transformation Hierarchies. CS 4620 Lecture 5

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

Design Patterns Reid Holmes

Event Dispatch. Interactor Tree Lightweight vs. Heavyweight Positional Dispatch Focus Dispatch. 2.4 Event Dispatch 1

COSC 3351 Software Design. Design Patterns Structural Patterns (II) Edgar Gabriel. Spring Decorator

Event Dispatch. Interactor Tree Lightweight vs. Heavyweight Positional Dispatch Focus Dispatch. Event Architecture. A pipeline: Event Capture

Pattern Examples Behavioural

The Null Object Pattern

Creational Design Patterns

LOG6306 : Études empiriques sur les patrons logiciels

Software Engineering Prof. Rushikesh K.Joshi IIT Bombay Lecture-15 Design Patterns

Design for change. You should avoid

Composite Pattern - Shapes Example - Java Sourcecode

Design Patterns Reid Holmes

Design Patterns. Paul Jackson. School of Informatics University of Edinburgh

Software Engineering Design & Construction

Slide 1. Design Patterns. Prof. Mirco Tribastone, Ph.D

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

Scene Graphs. COMP 575/770 Fall 2010

Introduction to Design Patterns

CHAIN OF RESPONSIBILITY (DP 223)

Introduction to Design Patterns

DESIGN PATTERNS SURESH BABU M ASST PROFESSOR VJIT

David Talby March 21, 2006

Transcription:

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt

Dr. Michael Eichberg Fachgebiet Software Engineering Department of Computer Science Technische Universität Darmstadt Introduction to Software Engineering The Composite Design Pattern For details see Gamma et al. in Design Patterns

Intent 3 Compose objects into tree structures to represent partwhole hierarchies Composite lets clients treat individual objects and compositions of objects uniformly

Motivation 4 Imagine a drawing editor where complex diagrams are build out of simple components and where the user wants to treat classes that (a) represent primitives and such that (b) represent components uniformly most of the time Example Picture contains elements Elements can be grouped Groups can contain other groups Suitcase 9,99!

Example Drawing 5 Suitcase 9,99! Object-Diagram :Group :Group tag:rectangle price:text handle:line case:rectangle name:text CorrespondingObject Diagram

Example 6 Suitcase 9,99! Object-Diagram :Group :Group tag:rectangle price:text handle:line case:rectangle name:text Element draw() Rectangle Line Text Group draw() draw() draw() draw() add(graphic) remove(graphic) getchild(int)

Applicability 7 Use composite when... you want to represent part-whole hierarchies of objects you want clients to be able to ignore the difference between individual and composed objects (Clients will treat all objects in the composite structure uniformly.)

Structure 8 Component {abstract} Client add(component) remove(component) getchild(int) children Leaf «method» { forall g in children g. } Composite add(component) remove(component) getchild(int)

Participants 9 Component Declares interface for objects in the composition Implements default behavior as appropriate (Often) declares an interface for accessing and managing child components Leaf Represents leaf objects in the composition; defines the primitive behavior Composite Stores children / composite behavior Client Accesses objects in the composition via Component interface

Collaborations 10 Clients interact with objects through the Component interface Leaf recipients react directly Composites forward requests to their children, possibly adding before/after operations Excursion: A pattern is a collaboration Object diagram for the context. Which roles are involved? Sequence diagram for interactions (Interaction diagram for context & interaction.) What is the order of method calls?

Consequences 11 "Primitive objects can be recursively composed "Clients can treat composites and primitives uniformly (Clients do not have to write tag-and-case statementstyle functions.) "New components can easily be added "Design may become overly general (You can t always rely on the type system to enforce certain constraints; e.g. that a composite has only certain components.)

Implementation 12 Explicit parent references May facilitate traversal and management of a composite structure; often defined in the component class. Need to be maintained. "Sharing components E.g. to reduce storage requirements it is often useful to share components. ( Flyweight Pattern) Size of the component interface To make clients unaware of the specific Leaf or Composite classes the Component class should define as many operations for Composite and Leaf as possible. (May require a little creativity.) (next page)

Structure 13 Component {abstract} Leaf Client Issue - General Design Principle: A class should only define methods meaningful to its subclasses. add(component) remove(component) getchild(int) Composite children Sometimes some creativity is needed! «method» { forall g in children g. } add(component) remove(component) getchild(int)

Implementation Placing child management operations - who declares them? at the root (Component) is convenient, but less safe because clients may try to do meaningless things in Composite is safe 14 Component {abstract} children Component {abstract} add(component) remove(component) getchild(int) children Composite declaration Composite Trade-off between safety and transparency. add(component) remove(component) getchild(int) add(component) remove(component) getchild(int)

Implementation Placing child management operations - who declares them? at the root (Component) is convenient, but less safe because clients may try to do meaningless things in Composite is safe 15 Component {abstract} Composite children Component {abstract} add(component) remove(component) getchild(int) Composite children How to avoid a downcast if you need access to a composite? declaration Trade-off between safety and transparency. add(component) remove(component) getchild(int) add(component) remove(component) getchild(int)

Example - Component Class 16 Computer equipment contains: drives, graphic cards in the PCIe slots, memory, and more. Such a part-whole structure can be modeled naturally with the Composite pattern.

Example - Component Class 17 public abstract class Equipment { private String name; public String name() { return name; } public abstract int price(); // more methods, e.g., for power consumption etc. } // Child management public abstract void add(equipment eq); public abstract void remove(equipment eq); public Iterator<Equipment> iterator(){ return NULL_ITERATOR; };

Example - Leaf Class 18 public class HardDisk extends Equipment { public int price() { return 50; } }...

Example - Composite Class 19 public class CompositeEquipment extends Equipment {... public int price() { int total = 0; for (int i=0; i < equipment.length; i++) total += equipment[i].price(); return total; } public void add(equipment eq) {...}; public void remove(equipment eq) {...}; } public Iterator<Equipment> iterator() {...};

Example - Demo Usage 20 public class Chassis extends CompositeEquipment{ } public class Bus extends CompositeEquipment{ } public class Card extends Equipment{ } public class Mainboard extends CompositeEquipment{ } }Further Definitions Chassis chassis = new Chassis(); Mainboard mainboard = new Mainboard( Hypermulticore ); Bus bus = new Bus("PCIe Bus"); DEMOCODE chassis.add(new HardDisk("Personal 1Tb Drive")); chasses.add(mainboard); mainboard.add(bus); bus.add(new Card("Graphics Card")); bus.add(new HardDisk("YetAnotherDisk")); // checks required...? System.out.println("Total price: " + chassis.price() );

Known Uses 21 View class of Model/View/Controller Application frameworks & toolkits ET++, 1988 Graphics, 1988 Glyphs, 1990 InterViews, 1992 Java (AWT, Swing, Files)

Related Patterns 22 Iterator Traverse composite Visitor To localize operations that are otherwise distributed across Composite and Leaf classes Chain of Responsibility Use components hierarchy for task solving Flyweight For sharing components

Summary 23 The Composite Design Pattern facilitates to compose objects into tree structures to represent partwhole hierarchies. Apply the composite pattern if clients can treat individual objects and compositions of objects uniformly.