patterns

The Decorator Pattern

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

 patterns

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

Decorator

 

Rainer D 6 P2 500x500Modernes C++ Mentoring

Be part of my mentoring programs:

  • "Fundamentals for C++ Professionals" (open)
  • "Design Patterns and Architectural Patterns with C++" (open)
  • "C++20: Get the Details" (open)
  • "Concurrency with Modern C++" (starts March 2024)
  • Do you want to stay informed: Subscribe.

     

    Component

    • Defines the common interface for the Decorator and the ConcreteComponent

    ConcreteComponent

    • The object to be decorated
    • It defines the basic behavior

    Decorator

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

    decoratorWiki

    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.

    decoratorFrame

     

    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. 

     

     

     

    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, Kris Kafka, 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, Dmitry Farberov, 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, moon, Philipp Lenk, Hobsbawm, and Charles-Jianye Chen.

    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

    Seminars

    I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

    Standard Seminars (English/German)

    Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.

    • C++ – The Core Language
    • C++ – The Standard Library
    • C++ – Compact
    • C++11 and C++14
    • Concurrency with Modern C++
    • Design Pattern and Architectural Pattern with C++
    • Embedded Programming with Modern C++
    • Generic Programming (Templates) with C++
    • Clean Code with Modern C++
    • C++20

    Online Seminars (German)

    Contact Me

    Modernes C++ Mentoring,

     

     

    0 replies

    Leave a Reply

    Want to join the discussion?
    Feel free to contribute!

    Leave a Reply

    Your email address will not be published. Required fields are marked *