1 / 18

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

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.

ainsley
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

More Related