1. 1 PH Chapter 1 (pp. 1-10) GoF Composite Pattern (pp. 163-173) PH Ch 2 through Fundamentals (pp. 11-16) Presentation by Julie Betlach 5/28/2009

2. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 2 Introduction Pattern Hatching (PH) book –Intended to be a supplement to Design Patterns: Elements of Reusable Object-Oriented Software written by the Gang of Four (GoF): Gamma, Helm, Johnson, and Vlissides –Pattern Hatching book was written by Vlissides. Pattern Hatching Introduction – PH pgs 1-10

3. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 3 Introduction – Top 10 Misconceptions (1) A pattern is a solution to a problem in a context. Why isn’t this true? –Patterns are applied to recurring problems (not one instance). –Patterns teach, so that the developer can tailor the solution to a variant of the problem. –Patterns have a name. Pattern Hatching Introduction – PH pgs 1-10

4. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 4 Introduction – Top 10 Misconceptions (2) Patterns are just jargon, rules, programming tricks, data structures, etc. –The idea of patterns is old… experienced programmers used previous solutions on new problems. –What is new is naming them and writing them down. –One drawback (from personal experience) is to assume everyone knows the pattern. Design documentation should note the name of the design pattern used, but that shouldn’t be the extent of the documentation. Pattern Hatching Introduction – PH pgs 1-10

5. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 5 Introduction – Top 10 Misconceptions (3) Seen one, seen them all. –Patterns are extremely diverse. –Don’t make assumptions about all patterns based on a few patterns. Pattern Hatching Introduction – PH pgs 1-10

6. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 6 Introduction – Top 10 Misconceptions (4) Patterns need tool or methodological support to be effective. –Benefits of patterns (no tool or support needed!) Patterns capture expertise and make it accessible to non- experts. Pattern names form a vocabulary which helps developers communicate. Documenting the design with the patterns in use helps people understand the system more quickly. Patterns facilitate restructuring a system whether or not it was designed with patterns in mind. Pattern Hatching Introduction – PH pgs 1-10

7. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 7 Introduction – Top 10 Misconceptions (5) Patterns guarantee reusable software, higher productivity, world peace, etc. –Patterns don’t guarantee anything. –Similar comments were made about object-oriented programming when it was introduced. (6) Patterns ‘generate’ whole architectures. –Need human creativity to know how to apply and tailor a pattern for your given problem. –Need to fill in the “white space” between the patterns. –Through teaching / discussion, patterns may support “generativity” – helping the reader solve problems that the pattern doesn’t address explicitly. Pattern Hatching Introduction – PH pgs 1-10

8. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 8 Introduction – Top 10 Misconceptions (7) Patterns are for (object-oriented) design or implementation. –Patterns capture expertise, but are not limited to design and implementation. –Patterns can be found in analysis, maintenance, testing, documentation, organizational structure, etc. –Two books have been written on Analysis Patterns. –1996 conference had a submission for patterns in music composition. Pattern Hatching Introduction – PH pgs 1-10

9. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 9 Introduction – Top 10 Misconceptions (8) There’s no evidence that patterns help anybody. –Improve teaching and communication. (9) The pattern community is a clique of elites. –Attendees of Pattern Languages of Programming (PLoP) conferences included analysts, designers, implementors, students, professionals, authors, even a non-computer scientist. (10) The pattern community is self-serving, even conspiratorial. –Common desire of leading pattern authors is to impart expertise, best practices, and competitive advantage to others. Pattern Hatching Introduction – PH pgs 1-10

10. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 10 Introduction – Observations Reactions to Design Patterns –Electronic Hobbyist going back to school Terminology may be new Familiar underlying concepts –Freshman taking the same classes Material is totally new, so may be difficult to understand and appreciate Pattern Hatching Introduction – PH pgs 1-10

11. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 11 Composite Pattern - Intent / Applicability Intent –Compose objects into tree structures to represent part-whole hierarchies. –Clients can treat individual objects and compositions of objects uniformly. Applicability – Use Composite Pattern when… –You want to represent part-whole hierarchies of objects. –You want clients to be able to ignore the differences between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.

12. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 12 Directory / File Example – Object Structure / bin/user/tmp/ file1 file2 subdir/file3 file4 file5 Composite Leaf Directory = Composite File = Leaf

13. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 13 Directory / File Example – Classes One class for Files (Leaf nodes) One class for Directories (Composite nodes) –Collection of Directories and Files How do we make sure that Leaf nodes and Composite nodes can be handled uniformly? –Derive them from the same abstract base class Leaf Class: FileComposite Class: Directory

14. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 14 Directory / File Example – Structure http://en.wikipedia.org/wiki/File:Composite_UML_class_diagram.svg Abstract Base Class: Node Leaf Class: FileComposite Class: Directory See page 12-13 of Pattern Hatching Book for example code.

15. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 15 Directory / File Example – Operation http://en.wikipedia.org/wiki/File:Composite_UML_class_diagram.svg Abstract Base Class: Node size() in bytes of entire directory and sub-directories Leaf Class: File size () of file Composite Class: Directory size () Sum of file sizes in this directory and its sub-directories long Directory::size () { long total = 0; Node* child; for (int i = 0; child = getChild(); ++i; { total += child->size(); } return total; }

16. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 16 Inventory Example – Problems to Consider http://en.wikipedia.org/wiki/File:Composite_UML_class_diagram.svg Abstract Base Class: Inventory Item Leaf Class: Object Composite Class: Container Backpack Cloth BagJeweled Dagger RubyRingWine Bottle Do you really want all leaf Operations to be defined in Component class? Is Wine Bottle a Composite or does it have an operation for Fill(Liquid)? If Ruby is pried from Dagger, how will this be handled? Would you allow user to put other items in the wine bottle? How do you handle the relative size of items to be placed in a backpack?

17. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 17 Consequences Solves problem of how to code recursive hierarchical part-whole relationships. Client code is simplified. –Client code can treat primitive objects and composite objects uniformly. –Existing client code does not need changes if a new leaf or composite class is added (because client code deals with the abstract base class). Can make design overly general. –Can’t rely on type system to restrict the components of a composite. Need to use run-time checks.

18. Composite Pattern – GoF pgs 163-173, PH pgs 11-16 18 Related Patterns Chain of Responsibility – Component-Parent Link Decorator – When used with composite will usually have a common parent class. So decorators will need to support the component interface with operations like: Add, Remove, GetChild. Flyweight – Lets you share components, but they can no longer reference their parents. Iterator – Can be used to traverse composites. Visitor – Localizes operations and behavior that would otherwise be distributed across composite and leaf classes.