Flutter Design Patterns: 16 — Decorator

An overview of the Decorator design pattern and its implementation in Dart and Flutter

Mangirdas Kazlauskas
Feb 28 · 8 min read

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

  • Analysis
  • Implementation
  • Other articles in this series
  • Your contribution

What is the Decorator design pattern?

When you see a separate class created for every possible combination of components (source)

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

Structure of the Decorator design pattern (source)
  • 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

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

Class Diagram — 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

PizzaBase

PizzaDecorator

Concrete pizza decorators

  • Basil:
  • Mozzarella:
  • Olive Oil:
  • Oregano:
  • Pecorino:
  • Pepperoni:
  • Sauce:

PizzaToppingData

PizzaMenu

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

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

Flutter Community

Articles and Stories from the Flutter Community

Mangirdas Kazlauskas

Written by

Software Engineer | Flutter Enthusiast https://www.linkedin.com/in/mangirdas-kazlauskas/

Flutter Community

Articles and Stories from the Flutter Community

More From Medium

More from Flutter Community

More from Flutter Community

More from Flutter Community

More from Flutter Community

DateField in Flutter Made Easy

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