Composite pattern 163 173 pattern hatching chpt 1 2 l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

Composite Pattern (163-173) Pattern Hatching Chpt 1-2 PowerPoint PPT Presentation


  • 186 Views
  • Uploaded on
  • Presentation posted in: General

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.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Composite pattern 163 173 pattern hatching chpt 1 2 l.jpg

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

Presentation by Joe Barzilai

1/30/2006


Composite pattern l.jpg

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 pattern3 l.jpg

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 pattern4 l.jpg

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 pattern5 l.jpg

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 pattern6 l.jpg

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.


Pattern hatching ch 1 l.jpg

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


The misconceptions l.jpg

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


Misconceptions cont l.jpg

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

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 cont11 l.jpg

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 cont12 l.jpg

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


Misconceptions cont13 l.jpg

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

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

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

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 example17 l.jpg

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


File structure example18 l.jpg

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;

    }


  • Login