The Composite Design Pattern is a structural design pattern with a recursive nature. In this article we will delve into it and hopefully we wont repeat ourselves too much.
We’ll go over a few things:
- What is it? 🤔
- Let’s look at an example 🚀
- Why do we need it? 😐
- Let’s see some code! 👩💻
What is it? 🤔
The Composite Design Pattern is a structural design pattern that is used to represent data and compose objects in the system into a tree-like structure.
It is worth describing to high-level concepts needed to understand how this pattern works.
In our system we will have either Single Objects, or Composite Objects.
Single Objects can be thought of as standalone objects that will implement similar behaviour matching a predefined contract.
Composite Objects are made up of either Single Objects and/or other Composite Objects.
🤯 Confused yet?
Let’s break it down a bit. Let’s say we buy a Printer at the store. It comes in a Box. When we open the Box, we see there is a Printer in the Box, but that there is also another Box along side it. This Box contains a Power Lead and a USB Adapter for the Printer.
We can think of the Printer itself as a Single Object, whilst the Box is a Composite Object. It is has a Printer and it has another Box. This nested Box has a Power Lead and a USB Adapter, both Single Objects, making this Box a Composite Object.
Hopefully that has made the concept clearer! ☀️
This structure then allows us to traverse the tree recursively through a single common interface as it allows us to treat single objects and compositions of objects uniformly.
Let’s look at an example 🚀
The best way to understand this Pattern is definitely to look at an example of it.
Let us think of an imaginary Task Runner. 🤖
We feed this Task Runner a set of
Task Instructions. But each
Task Instruction may have
Sub Task Instructions, and each
Sub Task Instruction might have its own
Sub Task Instructions.
We can see already that this has the potential for being a recursive structure.
We don’t necessarily want the Task Runner to have to check at each execution of each
Instruction if it is
Composite Instruction Set or a
Composite Instruction Set should contain a list of children of either
Composite Instruction Set or
Single Instruction that the Task Runner doesn't need to know about.
Therefore, to tackle this, we would define a common
Instruction interface containing an
execute() method that the
Composite Instruction Set and the
Single Instruction implement.
The Task Runner will Iterate through a list of
Instructions calling the
Single Instructions will execute their custom logic, whilst
Composite Instruction Sets will Iterate through their children and call their
They don’t need to know if their children are
Single Instructions, and the Task Runner also does not need to know the concrete makeup of the
Instructions it needs to run, allowing for a lot of flexibility!
Here is a diagram illustrating the example above:
Why do we need it? 😐
The core problem arises when we have different types of objects that have a similar behaviour or contain children that have similar behaviour.
Type checking before running the required logic isn’t desired as it will force the Client code to be tightly coupled to the structure of the objects it is working with to potentially iterate through children if required to do so.
Instead we want our objects themselves to know what their own logic needs to be to perform the action at hand, allowing us to traverse the Tree-like Structure recursively without needing to worry about what type each Leaf node within the Tree is.
Let’s see some code! 👩💻
Taking our Task Runner example above, let’s put it into code.
We need an interface to define common behaviour between
Single Instructions and
Now that we have our interface defined, we will define our
We want our
SingleInstructions to be flexible and extensible to allow developers to create custom instructions the Task Runner can understand.
For example purposes let’s create a Logging Instruction that will always
return true, but output a log.
Now that we have defined the Structure of our Task Instructions let’s create our Task Runner itself.
It’s as simple as that! The Task Runner doesn’t need to know or care what type of Instruction it is dealing with, so long as it can call it’s
execute() method, offloading the hard work to the Instructions themselves!
Let’s see the code in action.
Hopefully looking at this code has made the power of this particular Design Pattern stand out!
It can be used for all manner of tree-like shaped data systems from shopping carts to delivering packages containing packages!
Isn’t that awesome! 🚀🚀🚀
Hopefully you learned a bit ( more?) about the Composite Pattern from this article.
If you have any questions, feel free to ask below or reach out to me on Twitter: @FerryColum.
Originally published at https://dev.to on January 4, 2020.