16 - Decorator

Previously in the series, I have analysed a relatively simple, but very practical design pattern — Proxy. This time I would like to represent a design pattern, which, unlike the Strategy design pattern, extends the functionality of an object instead of exchanging it. It is a structural design pattern called Decorator.

Table of Contents

• What is the Decorator design pattern?
• Analysis
• Implementation
• Your Contribution

What is the Decorator design pattern?

Decorator, also known as Wrapper, is a structural design pattern, which intention in the GoF book is described like this:

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

The Decorator design pattern provides a way of changing the skin of an object without changing its guts — it extends an object’s functionality by wrapping it in an object of a Decorator class, leaving the original object intact without modification. Therefore, the pattern helps support one of the SOLID principles — the Open/Closed Principle (classes should be closed for modification, but open for extension).

The decorations (decorator classes) are independent of each other, hence they can be composed and chained together to add multiple behaviours (inception flashbacks, huh?). Also, another advantage is that this behaviour could be added at run-time, which leads to very flexible reuse of code, unlike using class inheritance. In addition to this, changing the order of decorators allows adding any combinations of responsibilities. However…

With great power comes great responsibility

The usage of the Decorator design pattern can also increase the complexity of code. To implement a specific component and make it modifiable at the run-time, not only you need to implement the Component, but also an indefinite amount of Decorator classes should be added to wrap it. A larger number of classes can sometimes be overwhelming, also debugging and testing the component wrapped by several additional classes does not make the development easier, too.

Let’s move to the analysis and implementation parts to understand and learn the details about this pattern and how to implement it!

Analysis

The general structure of the Decorator design pattern looks like this:

• Component — defines the interface for objects that can have responsibilities added to them dynamically;
• Concrete Component — defines an object to which additional responsibilities can be added. It contains the basic behaviour which can be altered by decorators;
• Base Decorator — has a field referencing a wrapped object which type should be declared as the component interface so it can contain both concrete components and decorators;
• Concrete Decorators — adds responsibilities (extra behaviour) to the components dynamically;
• Client — initialises the concrete component and wraps it in multiple layers of decorators extending its default behaviour dynamically.

Applicability

The Decorator design pattern should be used when you need to add extra responsibilities to objects dynamically (at run-time) without affecting other objects. Since all the decorator objects implement the same interface, they can be used in various combinations and interchanged with each other.

Also, this design pattern is useful when extension by subclassing is impractical or even not possible. For instance, sometimes a large number of independent extensions are possible and would produce a huge number of subclasses to support every combination — for those cases, the Decorator design pattern is a better option.

Finally, the Decorator design pattern could be simply used to refactor the code base and split components with hard-wired extensions (compile-time implementation dependencies) into separate classes. As a result, code becomes more readable/maintainable (there would be less code in smaller classes) and at the same time more flexible.

Implementation

In the Flutter community, it is quite popular to create food delivery/restaurant type of applications. With the implementation of the Decorator design pattern, we will jump into this hype train and will build a prototype for the pizza delivery application, to be more specific, for the pizza selection from the menu.

Let’s say we have a small restaurant which makes 3 kinds of pizza:

• Margherita — Sauce, Mozzarella, Basil, Oregano, Pecorino, Olive Oil;
• Pepperoni — Sauce, Mozzarella, Pepperoni, Oregano;
• “Make-Your-Own” — any combination of pizza toppings from the list of Basil, Mozzarella, Olive Oil, Oregano, Pecorino, Pepperoni, and Sauce.

All the pizzas are of the same size, pizza toppings have different prices.

It is quite clear for the pizza Margherita or Pepperoni — the recipe is clear, you just need to add the necessary toppings and calculate the final price, easy peasy. However, for the custom pizza, it would be very impractical to prepare the pre-defined recipes for all the possible combinations — that’s just not how it works usually from the business point of view.

For this problem, the Decorator design pattern is a great option since we can make the pizza toppings as separate decorator classes, use them to wrap the pizza base (the base component) and calculate the final price of the pizza based on the selected toppings. Let’s check the class diagram first and then implement the pattern.

Class diagram

The class diagram below shows the implementation of the Decorator design pattern:

Pizza defines a common interface for wrappers (decorators) and wrapped objects:

• getDescription() — returns the description of the pizza;
• getPrice() — returns the price of the pizza.

PizzaBase represents the component object which extends the Pizza class and implements its abstract methods.

PizzaDecorator references the Pizza object and forwards requests to it via the getDescription() and getPrice() methods.

Basil, Mozzarella, OliveOil, Oregano, Pecorino, Pepperoni and Sauce are concrete decorators extending the PizzaDecorator class and overriding its default behaviour by adding some extra functionality/calculations of their own.

PizzaToppingData class stores information about the pizza topping’s selection chip used in the UI — its label and whether it is selected or not.

PizzaMenu class provides a getPizzaToppingsDataMap() method to retrieve the pizza topping’s selection chip data. Also, getPizza() method is defined to return the specific Pizza object based on the selected index in the UI or the selected pizza toppings.

DecoratorExample initialises and contains the PizzaMenu class object to retrieve the selected Pizza object based on the user’s selection in the UI.

Pizza

An abstract class of the Pizza component that defines a common interface for concrete component and decorator objects.

PizzaBase

A concrete component that extends the Pizza class and implements its methods. An object of this class (its behaviour) gets decorated by the specific decorator classes.

PizzaDecorator

An abstract decorator class that maintains a reference to a component class and forwards requests to it.

Concrete pizza decorators

Basil, Mozzarella, OliveOil, Oregano, Pecorino, Pepperoni and Sauce are concrete decorator classes of the Pizza component. Each of these classes wraps the pizza object and adds additional value for the final price in the getPrice() method, also extends the final pizza’s description in the getDescription() method.

• Basil:

• Mozzarella:

• Olive Oil:

• Oregano:

• Pecorino:

• Pepperoni:

• Sauce:

PizzaToppingData

A simple class that contains data used by the pizza topping’s selection chip in the UI. The data consists of the label property and the current selection state (whether the chip is currently selected or not) which could be changed by using the setSelected() method.

PizzaMenu

A simple class that provides a map of PizzaToppingData objects via the getPizzaToppingsDataMap() method for the pizza toppings selection in UI. Also, the class defines a getPizza() method which returns a Pizza object that is built by using the pre-defined concrete decorator classes based on the pizza recipe — Margherita, Pepperoni or custom (based on the selected pizza toppings).

This class (to be more specific, getMargherita(), getPepperoni() and getCustom() methods) represents the main idea of the decorator design pattern — a base component class is instantiated and then wrapped by the concrete decorator classes, hence extending the base class and its behaviour. As a result, it is possible to use wrapper classes and add or remove responsibilities from an object at runtime, for instance, as it is used in the getCustom() method where the appropriate decorator classes are used based on the selected pizza toppings data in the UI.

Example

First of all, a markdown file is prepared and provided as a pattern’s description:

DecoratorExample contains the PizzaMenu object which is used to get the specific Pizza object based on the user’s selection. Also, all the logic related to the decorator’s design pattern and its implementation is extracted to the PizzaMenu class, the DecoratorExample widget only uses it to retrieve the necessary data to be represented in the UI.

The final result looks like this:

As you can see in the example when selecting any of the pre-defined recipes, the final price of the pizza is recalculated as well as the description of its toppings is provided. Also, for the custom pizza, the price is recalculated every time a topping is selected or deselected, the pizza’s description is updated, too.

All of the code changes for the Decorator design pattern and its example implementation could be found here.

Your Contribution

💖 or 🦄 this article to show your support and motivate me to write better!
💬 Leave a response to this article by providing your insights, comments or wishes for the next topic.
📢 Share this article with your friends, colleagues on social media.
➕ Follow me on dev.to or any other social media platform.
⭐ Star the Github repository.