The Decorator Pattern

The Decorator Pattern’s job is to extend an object with responsibilities dynamically. Let me, in today’s post, dig deeper.

First, the Decorator Pattern is the third structural pattern from the book “Design Patterns: Elements of Reusable Object-Oriented Software”, I present in my series about patterns. The first two ones were the Adapter Pattern and the Bridge Pattern.

Second, don’t confuse the Decorator Pattern with the Decorator Idiom in Python. Their intention is different. The Decorator Pattern allows you to extend objects dynamically, but the Decorator Idiom in Python enables you to extend functions dynamically.

Here are the facts about the Decorator Pattern.

Decorator Pattern

Purpose

Dynamically extends an object with responsibilities

Also known as

Wrapper

Use Case

Add or remove new responsibilities from individual objects at run time
The enhancement of the class hierarchy using subclassing (see Adapter Pattern) is not applicable

Structure

Component

Defines the common interface for the Decorator and the ConcreteComponent

ConcreteComponent

The object to be decorated
It defines the basic behavior

Decorator

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

Implements the interface of Component
It has a reference to the Component
It delegates all operations to the Component; the Component could either be an additional ConcreteDecorator or a ConcreteComponent

ConcreteDecorator

Extends the behavior of the Component
Overrides the member functions of its base Component
Calls typically in its overriding member function the overridden member function of it base Component

An important observation of the Decorator Pattern is that multiple decorators can be plugged on top of each other, with each decorator adding new functionality to the overridden member functions.

Example

The following example is based on the example in the Wikipedia page Decorator Pattern.

// decorator.cpp (based on https://en.wikipedia.org/wiki/Decorator_pattern)

#include <iostream>
#include <string>

struct Shape {
  virtual ~Shape() = default;

  virtual std::string GetName() const = 0;
};

struct Circle : Shape {
  void Resize(float factor) { radius *= factor; }

  std::string GetName() const override {
    return std::string("A circle of radius ") + std::to_string(radius);
  }

  float radius = 10.0f;
};

struct ColoredShape : Shape {
  ColoredShape(const std::string& color, Shape* shape)              // (1)
      : color(color), shape(shape) {}

  std::string GetName() const override {
    return shape->GetName() + " which is colored " + color + ".";   // (2)
  }

  std::string color;
  Shape* shape;
};

int main() {

  std::cout << '\n';

  Circle circle;
  ColoredShape colored_shape("red", &circle);
  std::cout << colored_shape.GetName() << '\n';

  std::cout << '\n';

}

In this example, Shape is the Component. Circle stands for the ConcreteComponent, and ColoredShape for the Decorator. ColoredShape gets it Shape in its constructor (line 1), invokes it shape->GetName() member function in line 2, and decorates it with its color.

Here is the output of the program:

Deriving a FramedShape as an additional Decorator, allows it to plug them together in arbitrary ways:

// decoratorFrame.cpp (based on https://en.wikipedia.org/wiki/Decorator_pattern)

#include <iostream>
#include <string>

struct Shape{
  virtual std::string str() const = 0;
};

class Circle : public Shape{
  float radius = 10.0f;
  
public:
  std::string str() const override{
    return std::string("A circle of radius ") + std::to_string(radius);
  }
};

class ColoredShape : public Shape{
  std::string color;
  Shape& shape;
public:
  ColoredShape(std::string c, Shape& s): color{c}, shape{s} {}
  std::string str() const override{
    return shape.str() + std::string(" which is coloured ") + color;
  }
};

class FramedShape : public Shape{
  Shape& shape;
public:
  FramedShape(Shape& s): shape{s} {}
  std::string str() const override{
    return shape.str() + std::string(" and has a frame");
  }
};

int main(){

  Circle circle;
  ColoredShape coloredShape("red", circle);    // (1)
  FramedShape framedShape1(circle);            // (2)
  FramedShape framedShape2(coloredShape);      // (3)
  
  std::cout << circle.str() << '\n';
  std::cout << coloredShape.str() << '\n';
  std::cout << framedShape1.str() << '\n';
  std::cout << framedShape2.str() << '\n';

}

The ColoredShape takes a Circle (line 1), the FramedShape a Circle (line 2), or a ColoredShape (line 3). The corresponding member functions str display the various combinations.

Related Patterns

The Composite Pattern is a structural pattern similar to the Decorator. The main difference is that the Decorator Pattern has only one child. Additionally, the Decorator Pattern adds new responsibility to an object, while the Composite Pattern sums up the results of its children.
The Adapter Pattern changes the interface of an object, but a Decorator extends the responsibilities of the object.
The Bridge Pattern‘s purpose is to separate the interface from the implementation. Decorators are pluggable, but neither bridges nor adapters.
The Strategy Pattern uses objects to change the implementation, but the Decorator uses objects to extend the responsibilities of the object.

Let’s talk about the pros and cons of the Decorator Pattern.

Pros and Cons

Pros

The decorators can be arbitrarily plugged on run time on top of each other.
Each decorator can implement a behavior variant and follow the single responsibility principle.

Cons

Due to these delegated member function calls, the control flow is difficult to follow.
The delegated member function call may affect the performance of the program.
It is pretty complicated to remove a decorator out of a stack of decorators.

What’s Next?

The Composite Pattern is a structural pattern and pretty similar to the Decorator Pattern. The main difference is that the Decorator Pattern has only one child. Additionally, the Decorator Pattern adds new responsibility to an object, while the Composite Pattern sums up the results of its children.

Post Views: 5,053

Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Stephen Kelley, Kyle Dean, Tusar Palauri, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
My special thanks to Take Up Code
My special thanks to SHAVEDYAKS