Composite Pattern 163173 Pattern Hatching Chpt 12

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
  components parent in the recursive structure,
  and implements it if thats 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 its destroyed
• Whats 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 arent 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 ones easy because patterns dont guarantee
  anything. They dont even make benefit likely.
• Patterns are just another weapon in the
  developers arsenal
• Misconception 6 Patterns generate whole
  architectures
• This misconception is like unto the last one,
  only its less aggressive in its overstatement
• Generativity refers to a patterns ability to
  create emergent behavior
• In other words, patterns help the reader solve
  problems that the pattern doesnt 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 dont generate anything,
  people do.

12
Misconceptions (cont)

• Misconception 7 Patterns are for
  (object-oriented) design or implementation
• Patterns are nothing if they dont capture
  expertise.
• There is expertise worth capturing in OO software
  design, but theres 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 Theres 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 weve 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
• Well call this Node
• We also know that directories aggregate files.
• Any ideas for a design pattern we can use?

17
File Structure Example

• Whats 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 Directorysize ()
• long total 0
• Node child
• for(int i 0 child getChild(i) i)
• total child-gtsize()
• return total