Composite Pattern 163 173 Pattern Hatching Chpt 1

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 (p 257) 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 (p 243) 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 not to apply them, which to apply, etc

The Misconceptions 1. There are three main types of misconceptions listed here: 1. 2. 3. 2. 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” 1. 2. Why is this a misconception? What is the definition missing? 1. 2. 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 1. 3. 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 (objectoriented) 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 • 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* get. Child(int n);

File Structure Example • get. Child 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 = get. Child(i); ++i){ total += child->size(); } return total; }