Decorator pattern
In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, dynamically, without affecting the behavior of other objects from the same class.[1] The decorator pattern is often useful for adhering to the Single Responsibility Principle, as it allows functionality to be divided between classes with unique areas of concern.[2] The decorator pattern is structurally nearly identical to the chain of responsibility pattern, the difference being that in a chain of responsibility, exactly one of the classes handles the request, while for the decorator, all classes handle the request.
Contents
1 Overview
2 Intent
3 Motivation
4 Usage
5 Structure
5.1 UML class and sequence diagram
6 Examples
6.1 C++
6.1.1 Dynamic Decorator
6.1.2 Static Decorator (Mixin Inheritance)
6.2 Java
6.2.1 First example (window/scrolling scenario)
6.2.2 Second example (coffee making scenario)
6.3 PHP
6.4 Python
6.5 Crystal
7 See also
8 References
9 External links
Overview
The Decorator
[3]
design pattern is one of the twenty-three well-known
GoF design patterns
that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.
What problems can the Decorator design pattern solve?
[4]
- Responsibilities should be added to (and removed from) an object dynamically at run-time.
- A flexible alternative to subclassing for extending functionality should be provided.
When using subclassing, different subclasses extend a class in different ways. But an extension is bound to the class at compile-time and can't be changed at run-time.
What solution does the Decorator design pattern describe?
Define Decorator objects that
- implement the interface of the extended (decorated) object (
Component) transparently by forwarding all requests to it and - perform additional functionality before/after forwarding a request.
This enables to work through different Decorator objects to extend the functionality of an object dynamically at run-time.
See also the UML class and sequence diagram below.
Intent
Decorator UML class diagram
The decorator pattern can be used to extend (decorate) the functionality of a certain object statically, or in some cases at run-time, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new Decorator class that wraps the original class. This wrapping could be achieved by the following sequence of steps:
- Subclass the original Component class into a Decorator class (see UML diagram);
- In the Decorator class, add a Component pointer as a field;
- In the Decorator class, pass a Component to the Decorator constructor to initialize the Component pointer;
- In the Decorator class, forward all Component methods to the Component pointer; and
- In the ConcreteDecorator class, override any Component method(s) whose behavior needs to be modified.
This pattern is designed so that multiple decorators can be stacked on top of each other, each time adding a new functionality to the overridden method(s).
Note that decorators and the original class object share a common set of features. In the previous diagram, the operation() method was available in both the decorated and undecorated versions.
The decoration features (e.g., methods, properties, or other members) are usually defined by an interface, mixin (a.k.a. trait) or class inheritance which is shared by the decorators and the decorated object. In the previous example the class Component is inherited by both the ConcreteComponent and the subclasses that descend from Decorator.
The decorator pattern is an alternative to subclassing. Subclassing adds behavior at compile time, and the change affects all instances of the original class; decorating can provide new behavior at run-time for selected objects.
This difference becomes most important when there are several independent ways of extending functionality. In some object-oriented programming languages, classes cannot be created at runtime, and it is typically not possible to predict, at design time, what combinations of extensions will be needed. This would mean that a new class would have to be made for every possible combination. By contrast, decorators are objects, created at runtime, and can be combined on a per-use basis. The I/O Streams implementations of both Java and the .NET Framework incorporate the decorator pattern.
Motivation
UML diagram for the window example
As an example, consider a window in a windowing system. To allow scrolling of the window's contents, one may wish to add horizontal or vertical scrollbars to it, as appropriate. Assume windows are represented by instances of the Window interface, and assume this class has no functionality for adding scrollbars. One could create a subclass ScrollingWindow that provides them, or create a ScrollingWindowDecorator that adds this functionality to existing Window objects. At this point, either solution would be fine.
Now, assume one also desires the ability to add borders to windows. Again, the original Window class has no support. The ScrollingWindow subclass now poses a problem, because it has effectively created a new kind of window. If one wishes to add border support to many but not all windows, one must create subclasses WindowWithBorder and ScrollingWindowWithBorder etc. This problem gets worse with every new feature or window subtype to be added. For the decorator solution, we simply create a new BorderedWindowDecorator—at runtime, we can decorate existing windows with the ScrollingWindowDecorator or the BorderedWindowDecorator or both, as we see fit. Notice that if the functionality needs to be added to all Windows, you could modify the base class and that will do. On the other hand, sometimes (e.g., using external frameworks) it is not possible, legal, or convenient to modify the base class.
Note, in the previous example, that the "SimpleWindow" and "WindowDecorator" classes implement the "Window" interface, which defines the "draw()" method and the "getDescription()" method, that are required in this scenario, in order to decorate a window control.
Usage
A decorator makes it possible to add or alter behavior of an interface at run-time. Alternatively, the adapter can be used when the wrapper must respect a particular interface and must support polymorphic behavior, and the Facade when an easier or simpler interface to an underlying object is desired.[5]
| Pattern | Intent |
|---|---|
| Adapter | Converts one interface to another so that it matches what the client is expecting |
| Decorator | Dynamically adds responsibility to the interface by wrapping the original code |
| Facade | Provides a simplified interface |
Structure
UML class and sequence diagram
In the above UML class diagram,
the abstract Decorator class maintains a reference (component)
to the decorated object (Component) and forwards all requests to it
(component.operation()).
This makes Decorator transparent (invisible) to clients of Component.
Subclasses (Decorator1,Decorator2) implement additional behavior
(addBehavior()) that should be added to the Component (before/after forwarding a request to it).
The sequence diagram
shows the run-time interactions: The Client object
works through Decorator1 and Decorator2 objects to
extend the functionality of a Component1 object.
The Client calls operation()
on Decorator1, which forwards the request to Decorator2.
Decorator2 performs addBehavior() after forwarding
the request to Component1 and returns to
Decorator1, which performs addBehavior()
and returns to the Client.
Examples
C++
Two options are presented here, first a dynamic, runtime-composable decorator (has issues with calling decorated functions unless proxied explicitly) and a decorator that uses mixin inheritance.
Dynamic Decorator
#include <iostream>
#include <string>
struct Shape
{
virtual std::string str() = 0;
};
struct Circle : Shape
{
float radius = 10.0f;
void resize(const float factor)
{
radius *= factor;
}
std::string str() override
{
return std::string("A circle of radius ") + std::to_string(radius);
}
};
struct ColoredShape : Shape
{
std::string color;
Shape* shape{nullptr};
ColoredShape(const std::string& clr, Shape* shp)
{
color = clr;
shape = shp;
}
std::string str() override
{
return shape->str() + std::string(" which is coloured ") + color;
}
};
// usage:
int main()
{
Circle c;
ColoredShape cc("red", &c);
std::cout << cc.str() << std::endl;
// cannot call this:
cc.resize(1.2); // not part of ColoredShape
return 0;
}
Static Decorator (Mixin Inheritance)
This example demonstrates a static Decorator implementation, which is possible due to C++ ability to inherit from the template argument.
#include <iostream>
#include <string>
struct Circle
{
float radius = 10.0f;
void resize(const float factor)
{
radius *= factor;
}
std::string str()
{
return std::string("A circle of radius ") + std::to_string(radius);
}
};
template <typename T> struct ColoredShape : T
{
std::string color;
ColoredShape(const std::string& clr)
{
color = clr;
}
std::string str()
{
return T::str() + " which is colored " + color;
}
};
// usage:
int main()
{
ColoredShape<Circle> red_circle("red");
std::cout << red_circle.str() << std::endl;
// and this is legal
red_circle.resize(1.5f);
std::cout << red_circle.str() << std::endl;
return 0;
}
Java
First example (window/scrolling scenario)
The following Java example illustrates the use of decorators using the window/scrolling scenario.
// The Window interface class
public interface Window {
void draw(); // Draws the Window
String getDescription(); // Returns a description of the Window
}
// Implementation of a simple Window without any scrollbars
class SimpleWindow implements Window {
@Override
public void draw() {
// Draw window
}
@Override
public String getDescription() {
return "simple window";
}
}
The following classes contain the decorators for all Window classes, including the decorator classes themselves.
// abstract decorator class - note that it implements Window
abstract class WindowDecorator implements Window {
protected Window windowToBeDecorated; // the Window being decorated
public WindowDecorator (Window windowToBeDecorated) {
this.windowToBeDecorated = windowToBeDecorated;
}
@Override
public void draw() {
windowToBeDecorated.draw(); //Delegation
}
@Override
public String getDescription() {
return windowToBeDecorated.getDescription(); //Delegation
}
}
// The first concrete decorator which adds vertical scrollbar functionality
class VerticalScrollBarDecorator extends WindowDecorator {
public VerticalScrollBarDecorator (Window windowToBeDecorated) {
super(windowToBeDecorated);
}
@Override
public void draw() {
super.draw();
drawVerticalScrollBar();
}
private void drawVerticalScrollBar() {
// Draw the vertical scrollbar
}
@Override
public String getDescription() {
return super.getDescription() + ", including vertical scrollbars";
}
}
// The second concrete decorator which adds horizontal scrollbar functionality
class HorizontalScrollBarDecorator extends WindowDecorator {
public HorizontalScrollBarDecorator (Window windowToBeDecorated) {
super(windowToBeDecorated);
}
@Override
public void draw() {
super.draw();
drawHorizontalScrollBar();
}
private void drawHorizontalScrollBar() {
// Draw the horizontal scrollbar
}
@Override
public String getDescription() {
return super.getDescription() + ", including horizontal scrollbars";
}
}
Here's a test program that creates a Window instance which is fully decorated (i.e., with vertical and horizontal scrollbars), and prints its description:
public class DecoratedWindowTest {
public static void main(String args) {
// Create a decorated Window with horizontal and vertical scrollbars
Window decoratedWindow = new HorizontalScrollBarDecorator (
new VerticalScrollBarDecorator (new SimpleWindow()));
// Print the Window's description
System.out.println(decoratedWindow.getDescription());
}
}
Below is the JUnit test class for the Test Driven Development
import static org.junit.Assert.assertEquals;
import org.junit.Test;
public class WindowDecoratorTest {
@Test
public void testWindowDecoratorTest() {
Window decoratedWindow = new HorizontalScrollBarDecorator(new VerticalScrollBarDecorator(new SimpleWindow()));
// assert that the description indeed includes horizontal + vertical scrollbars
assertEquals("simple window, including vertical scrollbars, including horizontal scrollbars", decoratedWindow.getDescription())
}
}
The output of this program is "simple window, including vertical scrollbars, including horizontal scrollbars". Notice how the getDescription method of the two decorators first retrieve the decorated Window's description and decorates it with a suffix.
Second example (coffee making scenario)
The next Java example illustrates the use of decorators using coffee making scenario.
In this example, the scenario only includes cost and ingredients.
// The interface Coffee defines the functionality of Coffee implemented by decorator
public interface Coffee {
public double getCost(); // Returns the cost of the coffee
public String getIngredients(); // Returns the ingredients of the coffee
}
// Extension of a simple coffee without any extra ingredients
public class SimpleCoffee implements Coffee {
@Override
public double getCost() {
return 1;
}
@Override
public String getIngredients() {
return "Coffee";
}
}
The following classes contain the decorators for all .mw-parser-output .monospaced{font-family:monospace,monospace}Coffee classes, including the decorator classes themselves..
// Abstract decorator class - note that it implements Coffee interface
public abstract class CoffeeDecorator implements Coffee {
protected final Coffee decoratedCoffee;
public CoffeeDecorator(Coffee c) {
this.decoratedCoffee = c;
}
public double getCost() { // Implementing methods of the interface
return decoratedCoffee.getCost();
}
public String getIngredients() {
return decoratedCoffee.getIngredients();
}
}
// Decorator WithMilk mixes milk into coffee.
// Note it extends CoffeeDecorator.
class WithMilk extends CoffeeDecorator {
public WithMilk(Coffee c) {
super(c);
}
public double getCost() { // Overriding methods defined in the abstract superclass
return super.getCost() + 0.5;
}
public String getIngredients() {
return super.getIngredients() + ", Milk";
}
}
// Decorator WithSprinkles mixes sprinkles onto coffee.
// Note it extends CoffeeDecorator.
class WithSprinkles extends CoffeeDecorator {
public WithSprinkles(Coffee c) {
super(c);
}
public double getCost() {
return super.getCost() + 0.2;
}
public String getIngredients() {
return super.getIngredients() + ", Sprinkles";
}
}
Here's a test program that creates a Coffee instance which is fully decorated (with milk and sprinkles), and calculate cost of coffee and prints its ingredients:
public class Main {
public static void printInfo(Coffee c) {
System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());
}
public static void main(String args) {
Coffee c = new SimpleCoffee();
printInfo(c);
c = new WithMilk(c);
printInfo(c);
c = new WithSprinkles(c);
printInfo(c);
}
}
The output of this program is given below:
Cost: 1.0; Ingredients: Coffee
Cost: 1.5; Ingredients: Coffee, Milk
Cost: 1.7; Ingredients: Coffee, Milk, Sprinkles
PHP
abstract class Component
{
protected $data;
protected $value;
abstract public function getData();
abstract public function getValue();
}
class ConcreteComponent extends Component
{
public function __construct()
{
$this->value = 1000;
$this->data = "Concrete Component:t{$this->value}n";
}
public function getData()
{
return $this->data;
}
public function getValue()
{
return $this->value;
}
}
abstract class Decorator extends Component
{
}
class ConcreteDecorator1 extends Decorator
{
public function __construct(Component $data)
{
$this->value = 500;
$this->data = $data;
}
public function getData()
{
return $this->data->getData() . "Concrete Decorator 1:t{$this->value}n";
}
public function getValue()
{
return $this->value + $this->data->getValue();
}
}
class ConcreteDecorator2 extends Decorator
{
public function __construct(Component $data)
{
$this->value = 500;
$this->data = $data;
}
public function getData()
{
return $this->data->getData() . "Concrete Decorator 2:t{$this->value}n";
}
public function getValue()
{
return $this->value + $this->data->getValue();
}
}
class Client
{
private $component;
public function __construct()
{
$this->component = new ConcreteComponent();
$this->component = $this->wrapComponent($this->component);
echo $this->component->getData();
echo "Client:ttt";
echo $this->component->getValue();
}
private function wrapComponent(Component $component)
{
$component1 = new ConcreteDecorator1($component);
$component2 = new ConcreteDecorator2($component1);
return $component2;
}
}
$client = new Client();
// Result: #quanton81
//Concrete Component: 1000
//Concrete Decorator 1: 500
//Concrete Decorator 2: 500
//Client: 2000
Python
The following Python example, taken from Python Wiki - DecoratorPattern, shows us how to pipeline decorators to dynamically add many behaviors in an object:
"""
Demonstrated decorators in a world of a 10x10 grid of values 0-255.
"""
import random
def s32_to_u16( x ):
if x < 0:
sign = 0xf000
else:
sign = 0
bottom = x & 0x00007fff
return bottom | sign
def seed_from_xy( x,y ): return s32_to_u16( x ) | (s32_to_u16( y ) << 16 )
class RandomSquare:
def __init__( s, seed_modifier ):
s.seed_modifier = seed_modifier
def get( s, x,y ):
seed = seed_from_xy( x,y ) ^ s.seed_modifier
random.seed( seed )
return random.randint( 0,255 )
class DataSquare:
def __init__( s, initial_value = None ):
s.data = [initial_value]*10*10
def get( s, x,y ):
return s.data[ (y*10)+x ] # yes: these are all 10x10
def set( s, x,y, u ):
s.data[ (y*10)+x ] = u
class CacheDecorator:
def __init__( s, decorated ):
s.decorated = decorated
s.cache = DataSquare()
def get( s, x,y ):
if s.cache.get( x,y ) == None:
s.cache.set( x,y, s.decorated.get( x,y ) )
return s.cache.get( x,y )
class MaxDecorator:
def __init__( s, decorated, max ):
s.decorated = decorated
s.max = max
def get( s, x,y ):
if s.decorated.get( x,y ) > s.max:
return s.max
return s.decorated.get( x,y )
class MinDecorator:
def __init__( s, decorated, min ):
s.decorated = decorated
s.min = min
def get( s, x,y ):
if s.decorated.get( x,y ) < s.min:
return s.min
return s.decorated.get( x,y )
class VisibilityDecorator:
def __init__( s, decorated ):
s.decorated = decorated
def get( s,x,y ):
return s.decorated.get( x,y )
def draw(s ):
for y in range( 10 ):
for x in range( 10 ):
print "%3d" % s.get( x,y ),
print
# Now, build up a pipeline of decorators:
random_square = RandomSquare( 635 )
random_cache = CacheDecorator( random_square )
max_filtered = MaxDecorator( random_cache, 200 )
min_filtered = MinDecorator( max_filtered, 100 )
final = VisibilityDecorator( min_filtered )
final.draw()
Note:
Please do not confuse the Decorator Pattern (or an implementation of this design pattern in Python - as the above example) with Python Decorators, a Python language feature. They are different things.
Second to the Python Wiki:
The Decorator Pattern is a pattern described in the Design Patterns Book. It is a way of apparently modifying an object's behavior, by enclosing it inside a decorating object with a similar interface.
This is not to be confused with Python Decorators, which is a language feature for dynamically modifying a function or class.[7]
Crystal
abstract class Coffee
abstract def cost
abstract def ingredients
end
# Extension of a simple coffee
class SimpleCoffee < Coffee
def cost
1.0
end
def ingredients
"Coffee"
end
end
# Abstract decorator
class CoffeeDecorator < Coffee
protected getter decorated_coffee : Coffee
def initialize(@decorated_coffee)
end
def cost
decorated_coffee.cost
end
def ingredients
decorated_coffee.ingredients
end
end
class WithMilk < CoffeeDecorator
def cost
super + 0.5
end
def ingredients
super + ", Milk"
end
end
class WithSprinkles < CoffeeDecorator
def cost
super + 0.2
end
def ingredients
super + ", Sprinkles"
end
end
class Program
def print(coffee : Coffee)
puts "Cost: #{coffee.cost}; Ingredients: #{coffee.ingredients}"
end
def initialize
coffee = SimpleCoffee.new
print(coffee)
coffee = WithMilk.new(coffee)
print(coffee)
coffee = WithSprinkles.new(coffee)
print(coffee)
end
end
Program.new
Output:
Cost: 1.0; Ingredients: Coffee
Cost: 1.5; Ingredients: Coffee, Milk
Cost: 1.7; Ingredients: Coffee, Milk, Sprinkles
See also
- Composite pattern
- Adapter pattern
- Abstract class
- Abstract factory
- Aspect-oriented programming
- Immutable object
References
^ Gamma, Erich; et al. (1995). Design Patterns. Reading, MA: Addison-Wesley Publishing Co, Inc. pp. 175ff. ISBN 0-201-63361-2..mw-parser-output cite.citation{font-style:inherit}.mw-parser-output q{quotes:"""""""'""'"}.mw-parser-output code.cs1-code{color:inherit;background:inherit;border:inherit;padding:inherit}.mw-parser-output .cs1-lock-free a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .cs1-lock-limited a,.mw-parser-output .cs1-lock-registration a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Lock-gray-alt-2.svg/9px-Lock-gray-alt-2.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .cs1-lock-subscription a{background:url("//upload.wikimedia.org/wikipedia/commons/thumb/a/aa/Lock-red-alt-2.svg/9px-Lock-red-alt-2.svg.png")no-repeat;background-position:right .1em center}.mw-parser-output .cs1-subscription,.mw-parser-output .cs1-registration{color:#555}.mw-parser-output .cs1-subscription span,.mw-parser-output .cs1-registration span{border-bottom:1px dotted;cursor:help}.mw-parser-output .cs1-hidden-error{display:none;font-size:100%}.mw-parser-output .cs1-visible-error{font-size:100%}.mw-parser-output .cs1-subscription,.mw-parser-output .cs1-registration,.mw-parser-output .cs1-format{font-size:95%}.mw-parser-output .cs1-kern-left,.mw-parser-output .cs1-kern-wl-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right,.mw-parser-output .cs1-kern-wl-right{padding-right:0.2em}
^ "How to Implement a Decorator Pattern". Archived from the original on 2015-07-07.
^ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley. pp. 175ff. ISBN 0-201-63361-2.CS1 maint: Multiple names: authors list (link)
^ "The Decorator design pattern - Problem, Solution, and Applicability". w3sDesign.com. Retrieved 2017-08-12.
^ Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates, Bert (2004). Hendrickson, Mike; Loukides, Mike, eds. "Head First Design Patterns" (paperback). 1. O'Reilly: 243, 252, 258, 260. ISBN 978-0-596-00712-6. Retrieved 2012-07-02.
^ "The Decorator design pattern - Structure and Collaboration". w3sDesign.com. Retrieved 2017-08-12.
^ "DecoratorPattern - Python Wiki". wiki.python.org.
External links
 | The Wikibook Computer Science Design Patterns has a page on the topic of: Decorator implementations in various languages |
Decorator Pattern implementation in Java- Decorator pattern description from the Portland Pattern Repository
