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.
- Dynamically extends an object with responsibilities
Also known as
- 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
- Defines the common interface for the
- The object to be decorated
- It defines the basic behavior
- Implements the interface of
- It has a reference to the
It delegates all operations to the
Component;the Component could either be an additional
- Extends the behavior of the
- Overrides the member functions of its base
- Calls typically in its overriding member function the overridden member function of it base
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.
The following example is based on the example in the Wikipedia page Decorator Pattern.
In this example,
Shape is the
Component. Circle stands for the
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
Here is the output of the program:
FramedShape as an additional
Decorator, allows it to plug them together in arbitrary ways:
ColoredShape takes a
Circle (line 1), the
FramedShape a Circle (line 2), or a C
oloredShape (line 3). The corresponding member functions
str display the various combinations.
- 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
- 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.
- 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.
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, Matthieu Bolt, 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, and Philipp Lenk.
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|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
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++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,