Presentation by Julie Betlach 5/28/2009

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. Pattern Hatching Introduction – PH pgs 1-10 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.

3. Pattern Hatching Introduction – PH pgs 1-10 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.

4. Pattern Hatching Introduction – PH pgs 1-10 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.

5. Pattern Hatching Introduction – PH pgs 1-10 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.

6. Pattern Hatching Introduction – PH pgs 1-10 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.

7. Pattern Hatching Introduction – PH pgs 1-10 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.

8. Pattern Hatching Introduction – PH pgs 1-10 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.

9. Pattern Hatching Introduction – PH pgs 1-10 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.

10. Pattern Hatching Introduction – PH pgs 1-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

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. Directory / File Example – Object Structure • Directory = Composite • File = Leaf / bin/ user/ tmp/ file1 subdir/ file3 file2 file5 file4 Composite Composite Composite Composite Leaf Leaf Composite Leaf Leaf Leaf

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: File Composite Class: Directory

14. Directory / File Example – Structure Abstract Base Class: Node Leaf Class: File Composite Class: Directory See page 12-13 of Pattern Hatching Book for example code. http://en.wikipedia.org/wiki/File:Composite_UML_class_diagram.svg

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

16. Inventory Example – Problems to Consider Abstract Base Class: Inventory Item Backpack Cloth Bag Jeweled Dagger Ruby Ring Wine Bottle Leaf Class: Object Composite Class: Container 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? http://en.wikipedia.org/wiki/File:Composite_UML_class_diagram.svg

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