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

1. Composite Pattern (163-173)Pattern Hatching Chpt 1-2 Presentation by Joe Barzilai 1/30/2006

2. 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

3. 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

4. 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

5. 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

6. 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.

7. 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

8. 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

9. 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

10. 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

11. 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.

12. 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

13. 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

14. 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

15. 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?)

16. 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?

17. 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);

18. 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; }