Composite Design Pattern

1
Composite Design Pattern

• Brian Hutcheson
• Mylan Nguyen
• Thoi Nguyen

2
Outline

• Intent
• Motivation
• Applicability
• Structure Participants
• Collaborations

• Consequences
• Sample Code
• Implementation
• Known uses
• Related Patterns

3
Intent

• Represents part-whole hierarchies using tree
  structures
• Lets clients treat individual objects and
  compositions of objects uniformly

4
Motivation

• Example A Graphics Program
• Simple objects (line, circle, square) combine to
  form complex objects
• Complex objects combine to form more complex
  objects
• Implementation includes classes for graphical
  primitives and containers for primitives
• Problem
• Code using the classes treats primitives and
  containers differently but user treats them the
  same, distinguishing objects makes the
  application more complex
• Solution
• The composite pattern describes how to use
  recursive composition so clients do not have to
  distinguish between objects

5
Motivation
6
Motivation

• Because the Picture interface conforms to Graphic
  interface,
• Picture objects can compose other Pictures
  recursively

7
Applicability

• The Composite pattern is used 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 and treat all objects
  uniformly

8
Participants

• Four Participants
• Client
• Component
• Composite
• Leaf

9
Example of the structure

• The client is the application

10
Client

• The client is an application
• The client manipulates objects in the composition
  through the Component interface
• Ex. Graphic Application

11
Component

• Component is an object in a composition
• 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
• Optionally provides access to the parent
  component

12
Composite

• Composite is a component with children
• Defines behavior for components
• Stores child components
• Implement child-related operations

13
Leaf

• Leaf is a component with no children
• Represents leaf objects in the composition
• Defines behavior for primitive objects in the
  composition

14
Collaborations

• Clients use the Component class interface to
  interact with objects.
• If the recipient is a Leaf, then the request is
  handled directly
• If the recipient is a Composite, then it usually
  forwards requests to its child components

15
Consequences

• Define recursive compositions of primitive and
  composite objects
• Makes the client simple. They dont need to know
  whether they deal with leaves or composites.
• Makes it easier to add new kinds of components.
• Can make your design overly general. You cant
  rely on types to constrain the structure.

16
Questions 1

• What are the four participants of the composite
  pattern?

17
Answer 1

• Four participants
• Client
• Component
• Composite
• Leaf

18
Question 2

• Arithmetic expression ( , -, , /) can be
  expressed as trees where an operand can be a
  number or an arithmetic expression. Since the
  individual objects, and compositions of
  individual objects are treated uniformly, an
  arithmetic expression is an example of the
  Composite pattern.
• Draw a composite structure for this expression
  6 2 ( 3 1 2) 2

19
Hint

• 6 2 ( 3 1 2) 2

20
Implementation Considerations

• Explicit Parent References
• Sharing Components
• Maximizing the Component Interface
• Declaring the child management operations
• Child Ordering
• Caching to improve performance

21
Implementation Considerations

• Explicit Parent References
• Simplifies tree traversal and management
• Supports Chain of Responsibility pattern
• Parent reference defined in the component class
• Only change parent from within methods of the
  Composite class
• Sharing Components
• Composite classes sharing children reduces
  storage requirements
• Sharing can lead to ambiguities as messages
  propagate up the structure (see Chain of
  Responsibility pattern).
• One solution apply the Flyweight pattern

22
Implementation Considerations Maximizing the
Component Interface

• Maximize transparency
• Define as many common operations in the Component
  class as possible
• Allow Leaf and Composite to override as needed.
• Violates the principle that child classes should
  only inherit meaningful operations
• Transparency tradeoff is worthwhile
• the Component class could implement default
  methods that basically do nothing.
• Example implementing a getChildren() operation
  that always returns no children.
• Leaf classes use the default implementation
• Composite classes can override this operation
  with something more meaningful.

23
Implementation Considerations

• Declaring the Child Management Operations
• Declaring Add and Remove operations in the
  Component provides TRANSPARENCY
• Declaring Add and Remove operations in the
  Composite provides SAFETY
• Possible compromise define operations in the
  Component, but have them fail by default
• Child Ordering
• Child ordering can be important consideration in
  some designs
• When ordering is important, design child access
  operations to manage the sequence of children

24
Implementation Considerations Caching

• It is common that designs will need to traverse
  compositions frequently.
• Example A GUI composite caches images of the
  current state of a GUI widget
• If the state of the GUI widgets does not change,
  they will not have to be redrawn
• Changes to a component requires invalidating its
  parents

25
Possible Composite Pattern Applications
?
26
Possible Composite Pattern Applications

• GUI containers and widgets
• HTML / XML Parsing
• J2EE Composite Entity beans
• File management