Design Patterns: CompositeBlog

Introduction

This post gives a brief overview about the Composite Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Composite Pattern?

The Composite pattern describes a group of objects that is treated the same way as a single instance of the same type of object. The intent of a composite is to “compose” objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

What problems can the Composite design pattern solve?

• A part-whole hierarchy should be represented so that clients can treat part and whole objects uniformly.
• A part-whole hierarchy should be represented as tree structure.

When defining (1) Part objects and (2) Whole objects that act as containers for Part objects, clients must treat them separately, which complicates client code.

What solution does the Composite design pattern describe?

• Define a unified Component interface for both part (Leaf) objects and whole (Composite) objects.
• Individual Leaf objects implement the Component interface directly, and Composite objects forward requests to their child components.

This enables clients to work through the Component interface to treat Leaf and Composite objects uniformly: Leaf objects perform a request directly, and Composite objects forward the request to their child components recursively downwards the tree structure. This makes client classes easier to implement, change, test, and reuse.

UML Diagram

The following diagram shows the Composite Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

You can click on the diagram to open it online in Pladitor.

Diagram Sources

Here are the diagram sources:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

@startuml
hide empty fields
hide empty methods

class Client
class Component
class Leaf
class Composite

Component : operation()
Component : add(Component)
Component : remove(Component)
Component : getChild(int)

Leaf : operation()

Composite : operation()
Composite : add(Component)
Composite : remove(Component)
Composite : getChild(int)

Client -> Component
Component <|-- Leaf
Component <|-- Composite
Component "0..*" <--o "1" Composite

note top of Client
The Client uses the
Component interface to
manipulate the objects in the
composition.
end note

note top of Component
The Component defines an
interface for all objects in
the composition: both the
composite and the leaf nodes.
end note

note top of Component
The Component may implement a
default behavior for add(), remove(),
getChild() and its operations.
end note

note bottom of Leaf
A Leaf has no
children.
end note

note left of Leaf
Note that the Leaf also
inherits methods like add(),
remove() and getChild(), which
do not necessarily make a lot of
sense for a leaf node. We are
going to come back to this issue.
end note

note bottom of Leaf
A Leaf defines the behavior for the
elements in the composition. It does
this by implementing the operations
the Composite supports.
end note

note bottom of Composite
The Composite’s role is to define
behavior of the components
having children and to store child
components.
end note

note right of Composite
The Composite also
implements the Leaf-
related operations.
Note that some of
these may not make
sense on a Composite,
so in that case an
exception might be
generated.
end note
@enduml

Open this diagram online with Pladitor.