Composite Pattern (163-173)Pattern Hatching Chpt 1-2

Presentation by Joe Barzilai

1/30/2006

Composite Pattern

• Intent– Compose objects into tree structures to

represent part-whole hierarchies.– Composite lets clients treat individual objects

and compositions of objects uniformly.

• Motivation– Graphic, Line, Text, Picture

Composite Pattern

• Applicability (use the pattern when…)– You want to represent part-whole hierarchies

of objects– You want clients to be able to ignore the

difference between compositions of objects and individual objects

Composite Pattern• Participants

– Component (Graphic)• Declares the interface for objects in the composition• Implements default behavior for the interface common to all classes, as

appropriate• Declares an interface for accessing and managing its child components• (Optional) Defines an interface for accessing a component’s parent in the

recursive structure, and implements it if that’s appropriate– Leaf (Line, Text, Rectangle)

• Represents the leaf objects in the composition. A leaf has no children• Defines behavior for primitive objects in the composition.

– Composite (Picture)• Defines behavior for components having children• Stores child components.• Implements child-related operations in the Component interface

– Client• Manipulates objects in the compostion through the Component interface

Composite Pattern

• Consequences– See board

• Implementation– Explicit Parent References– Sharing Components

• Share components to reduce storage requirements• Becomes difficult when?• Which pattern makes this easier?

– Maximizing the Component Interface• Component class should define as many common operations

for the Composite and Leaf classes as possible– Declaring the Child Management Operations

• Transparency vs Safety

Composite Pattern• Implementations (cont.)

– Should Component Implement a List of Components?– Child Ordering

• Sometimes it is useful to provide ordering. To do this just be careful when writing your Add/Remove children methods

• Iterator pattern (p257) comes in handy here– Caching to Improve Performance

• If caching is needed extra caching information should be stored in the Composite class

– Who Should Delete Components?• In a language without Garbage Collection its best to have Composite

responsible for deleting its children when it’s destroyed– What’s the Best Data Structure for Storing Components?

• Basically any will work (Linked List, trees, arrays, Hash Tables, etc)• The trick to choosing will be (as per usual) the efficiency trade-offs• Sometimes composites have a variable for each child, although this requires

each subclass of Composite to implement its own management interface. See Interpreter (p243) for an example.

Pattern Hatching Ch 1

• Can anyone (in a sentence or two) tell me the Intent of the Composite Pattern?

• This book is a collection of articles that John Vlissides wrote for C++ Report

• Where Design Patterns is more a catalog of patterns, Pattern Hatching is more the how-to of patterns.– How-to apply them, when to apply them, when

not to apply them, which to apply, etc

The Misconceptions• There are three main types of misconceptions listed here:

– What patterns are (1-4)– What patterns can do (5-8)– Who is the patterns community (9-10)

• Misconception 1 - “A pattern is a solution to a problem in a context”

– Why is this a misconception?– What is the definition missing?

• Recurrence, which makes the solution relevant in situations outside the immediate one

• Teaching, which gives you the understanding to tailor the solution to a variant of the problem– Most of the teaching in real patterns lies in the description and resolution of

forces, and/or the consequences of application• A name by which to refer to the pattern

Misconceptions (cont.)

• Misconception 2 – “Patterns are just jargon, rules, programming tricks, data structures…”– AKA “the belittling dismissal”– Patterns are not jargon, they rarely offer new terms– Patterns aren’t rules you can apply mindlessly (the

teaching component works against that)– Patterns are also not limited to programming tricks,

either• Saying that a pattern is a trick means that it overemphasizes

solution at the expense of problem, context, teaching and naming

Misconception (cont.)• Misconception 3 – “Seen one, seen them all”

– Broad-brushing is unfair as a rule and that goes double for pattern broad-brushing

– The patterns themselves are incredibly diverse in content, scope, style, domain and quality

• Misconception 4 – “Patterns need tool or methodological support to be effective”– The benefit from patterns comes mostly from applying them as they are

– that is, with no support of any kind– There are four main benefits of patterns:

• They capture expertise and make it accessible to nonexperts• Their names collectively form a vocabulary that helps developers

communicate• They help people understand a system more quickly when it is documented

with the patterns it uses• They facilitate restructuring a system whether or not it was designed with

patterns in mind– In short, patterns are primarily food for the brain, not fodder for a tool

Misconceptions (cont)

• Misconception 5 – “Patterns guarentee reusable software, higher productivity, world peace, etc”– This one’s easy because patterns don’t guarantee anything.

They don’t even make benefit likely.– Patterns are just another weapon in the developer’s arsenal

• Misconception 6 – “Patterns ‘generate’ whole architectures”– This misconception is like unto the last one, only it’s less

aggressive in its overstatement– Generativity refers to a pattern’s ability to create emergent

behavior• In other words, patterns help the reader solve problems that the

pattern doesn’t address explicitly– The key to generativity is in the parts of a pattern dedicated to

teaching. These insights help you define and refine an architecture but patterns themselves don’t generate anything, people do.

Misconceptions (cont)

• Misconception 7 – “Patterns are for (object-oriented) design or implementation”– Patterns are nothing if they don’t capture expertise.

• There is expertise worth capturing in OO software design, but there’s just as much to be had in non OO design

• And not just design but analysis, maintenance, testing, documentation, organizational structure, and on and on

• Misconception 8 – “There’s no evidence that patterns help anybody”– Um, why are we taking this class again

Misconceptions (cont)

• Misconception 9 – “The pattern community is a clique of elites”

• Misconception 10 – “The pattern community is self-serving, even conspiratorial”

• Observations:– Once past the fallacies, people tend to react to design

patterns in one of two ways:• Professional that has been in the field, that when he is taught

design patterns it is what he has been doing all along• Freshmen learning the patterns, they are completely foreign

to him

Pattern Hatching Ch. 2

• The best way to get a feel for using patterns is to use them

• So, lets design something: a hierarchical file system– The API specifically

Chapter 2

• Fundamentals– What needs to go into a file system?– Two Things are clear at outset:

• Files and directories are key elements in the problem domain• We need to have a way to introduce specialized versions of

these elements after we’ve finalized the design

– An obvious design approach is to represent the elements as objects

– How do you implement such a structure?• Two kinds of objects suggests two classes

– One for files, one for directories– Need to treat them uniformly (What do we need then?)

File Structure Example

• We need a common interface– Which means that the classes must be

derived from a common (abstract) base class• We’ll call this Node

– We also know that directories aggregate files.

• Any ideas for a design pattern we can use?

File Structure Example

• What’s the common interface going to look like?

• What attributes of common interest should we include?– Accessors, mutators

• For example, users ask for a list of files:– Thus, Directory needs an interface for

enumerating children• Virtual Node* getChild(int n);

File Structure Example

• getChild is also key to letting us define Directory operations recursively

• A size method for example:long Directory::size () {

long total = 0;Node* child;for(int i = 0; child = getChild(i); ++i){

total += child->size();}return total;

}