In software engineering, the composite pattern is a partitioning design pattern. The composite pattern describes a group of objects that are 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.
Overview
The Composite
design pattern is one of the twenty-three well-known
GoF design patterns
that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.
Problems
The Composite pattern solves these problems:
- Represent a part-whole hierarchy so that clients can treat part and whole objects uniformly.
- Represent a part-whole hierarchy as tree structure.
When defining (1) <code>Part</code> objects and (2) <code>Whole</code> objects that act as containers for <code>Part</code> objects, clients must treat them separately, which complicates client code.
Solution
- Define a unified <code>Component</code> interface for part (<code>Leaf</code>) objects and whole (<code>Composite</code>) objects.
- Individual <code>Leaf</code> objects implement the <code>Component</code> interface directly, and <code>Composite</code> objects forward requests to their child components.
This enables clients to work through the <code>Component</code> interface to treat <code>Leaf</code> and <code>Composite</code> objects uniformly:
<code>Leaf</code> objects perform a request directly,
and <code>Composite</code> objects
forward the request to their child components recursively downwards the tree structure.
This makes client classes easier to implement, change, test, and reuse.
See also the UML class and object diagram below.
Motivation
When dealing with Tree-structured data, programmers often have to discriminate between a leaf-node and a branch. This makes code more complex, and therefore, more error prone. The solution is an interface that allows treating complex and primitive objects uniformly. In object-oriented programming, a composite is an object designed as a composition of one-or-more similar objects, all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them. The operations you can perform on all the composite objects often have a least common denominator relationship. For example, if defining a system to portray grouped shapes on a screen, it would be useful to define resizing a group of shapes to have the same effect (in some sense) as resizing a single shape.
When to use
Composite should be used when clients ignore the difference between compositions of objects and individual objects.]]
In the above UML class diagram, the <code>Client</code> class doesn't refer to the <code>Leaf</code> and <code>Composite</code> classes directly (separately).
Instead, the <code>Client</code> refers to the common <code>Component</code> interface and can treat <code>Leaf</code> and <code>Composite</code> uniformly.
<br>
The <code>Leaf</code> class has no children and implements the <code>Component</code> interface directly.
<br>
The <code>Composite</code> class maintains a container of child
<code>Component</code> objects (<code>children</code>) and forwards requests
to these <code>children</code> (<code>for each child in children: child.operation()</code>).
<br>
The object collaboration diagram
shows the run-time interactions: In this example, the <code>Client</code> object sends a request to the top-level <code>Composite</code> object (of type <code>Component</code>) in the tree structure.
The request is forwarded to (performed on) all child <code>Component</code> objects
(<code>Leaf</code> and <code>Composite</code> objects) downwards the tree structure.<br>
;Defining Child-Related Operations
frame|none|Defining child-related operations in the Composite design pattern.
There are two design variants for defining and implementing child-related operations
like adding/removing a child component to/from the container (<code>add(child)/remove(child)</code>) and accessing a child component (<code>getChild()</code>):
- Design for transparency: Child-related operations are defined in the <code>Component</code> interface. This enables clients to treat <code>Leaf</code> and <code>Composite</code> objects uniformly. But type safety is lost because clients can perform child-related operations on <code>Leaf</code> objects.
- Design for type safety: Child-related operations are defined only in the <code>Composite</code> class. Clients must treat <code>Leaf</code> and <code>Composite</code> objects differently. But type safety is gained because clients cannot perform child-related operations on <code>Leaf</code> objects.
The GoF authors present a variant of the Composite design pattern that emphasizes transparency over type safety and discuss the tradeoffs of the two approaches.
Example
<!-- Wikipedia is not a list of examples. Do not add examples from your favorite programming language here; this page exists to explain the design pattern, not to show how it interacts with subtleties of every language under the sun. Feel free to add examples here: http://en.wikibooks.org/wiki/Computer_Science_Design_Patterns/Composite -->
This C++23 implementation is based on the pre C++98 implementation in the book.
<syntaxhighlight lang="c++">
import std;
using std::runtime_error;
using std::shared_ptr;
using std::string;
using std::unique_ptr;
using std::vector;
// Component object
// declares the interface for objects in the composition.
class Equipment {
private:
string name;
double netPrice;
protected:
Equipment() = default;
explicit Equipment(const string& name):
name{name}, netPrice{0} {}
public:
// implements default behavior for the interface common to all classes, as appropriate.
nodiscard
virtual const string& getName() const noexcept {
return name;
}
virtual void setName(const string& name) noexcept {
this->name = name;
}
nodiscard
virtual double getNetPrice() const noexcept {
return netPrice;
}
virtual void setNetPrice(double netPrice) noexcept {
this->netPrice = netPrice;
}
// declares an interface for accessing and managing its child components.
virtual void add(shared_ptr<Equipment>) = 0;
virtual void remove(shared_ptr<Equipment>) = 0;
virtual ~Equipment() = default;
};
// Composite object
// defines behavior for components having children.
class CompositeEquipment: public Equipment {
private:
// stores child components.
using EquipmentList = vector<shared_ptr<Equipment>>;
EquipmentList equipments;
protected:
CompositeEquipment() = default;
explicit CompositeEquipment(const string& name):
Equipment(name), equipments{EquipmentList()} {}
public:
// implements child-related operations in the Component interface.
nodiscard
virtual double getNetPrice() const noexcept override {
double total = Equipment::getNetPrice();
for (const Equipment& i: equipments) {
total += i->getNetPrice();
}
return total;
}
virtual void add(shared_ptr<Equipment> equipment) override {
equipments.push_back(equipment.get());
}
virtual void remove(shared_ptr<Equipment> equipment) override {
equipments.remove(equipment.get());
}
};
// Leaf object
// represents leaf objects in the composition.
class FloppyDisk: public Equipment {
public:
explicit FloppyDisk(const String& name):
Equipment(name) {}
// A leaf has no children.
void add(shared_ptr<Equipment>) override {
throw runtime_error("FloppyDisk::add() cannot be called!");
}
void remove(shared_ptr<Equipment>) override {
throw runtime_error("FloppyDisk::remove() cannot be called!");
}
};
class Chassis: public CompositeEquipment {
public:
explicit Chassis(const string& name):
CompositeEquipment(name) {}
};
int main() {
shared_ptr<FloppyDisk> fd1 = std::make_shared<FloppyDisk>("3.5in Floppy");
fd1->setNetPrice(19.99);
std::println("{}: netPrice = {}", fd1->getName(), fd1->getNetPrice);
shared_ptr<FloppyDisk> fd2 = std::make_shared<FloppyDisk>("5.25in Floppy");
fd2->setNetPrice(29.99);
std::println("{}: netPrice = {}", fd2->getName(), fd2->getNetPrice);
unique_ptr<Chassis> ch = std::make_unique<Chassis>("PC Chassis");
ch->setNetPrice(39.99);
ch->add(fd1);
ch->add(fd2);
std::println("{}: netPrice = {}", ch->getName(), ch->getNetPrice);
fd2->add(fd1);
}
</syntaxhighlight>
The program output is
<syntaxhighlight lang="c++">
3.5in Floppy: netPrice=19.99
5.25in Floppy: netPrice=29.99
PC Chassis: netPrice=89.97
terminate called after throwing an instance of 'std::runtime_error'
what(): FloppyDisk::add
</syntaxhighlight>
See also
- Perl Design Patterns Book
- Mixin
- Law of Demeter
References
External links
- Composite Pattern implementation in Java
- Composite pattern description from the Portland Pattern Repository
- Composite pattern in UML and in LePUS3, a formal modelling language
- Class::Delegation on CPAN
- "The End of Inheritance: Automatic Run-time Interface Building for Aggregated Objects" by Paul Baranowski
- PerfectJPattern Open Source Project, Provides componentized implementation of the Composite Pattern in Java
- [https://web.archive.org/web/20090531030742/http://www.theresearchkitchen.com/blog/archives/57] A persistent Java-based implementation
- Composite Design Pattern