The Composite Pattern — Design Patterns Meet the Frontend

Jan 4 · 4 min read

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 `Single Instruction`.

The `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 `execute()` method.

`Single Instructions` will execute their custom logic, whilst `Composite Instruction Sets` will Iterate through their children and call their `execute()` method.

They don’t need to know if their children are `Composite` or `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 `Composite Instructions`.

Now that we have our interface defined, we will define our `SingleInstruction` and `CompositeInstructionSet` classes.

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! 🚀🚀🚀

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.

Written by

JavaScript in Plain English

Learn the web's most important programming language.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just \$5/month. Upgrade