Decorator pattern

src: i.ytimg.com

In object-oriented programming, decorator patterns are design patterns that allow behavior to be added to individual objects, either statically or dynamically, without affecting the behavior of other objects of the same class. Decorator patterns are often useful for complying with the Single Responsibility Principle, as they allow functionality to be shared between classes with special areas of concern. The decorator pattern is structurally almost identical to the chain of responsibility patterns, the difference being that in the chain of responsibility, exactly one of the classes handles the request, while for the decorator, all classes handle the request.

Video Decorator pattern

Ikhtisar

Decorator design patterns are one of the twenty-three well-known GoF design patterns that describe how to solve repetitive design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, modify, test, and use back.

What issues can be resolved by the Decorator design pattern?

• Responsibility should be added to (and deleted from) an object dynamically at run-time.
• A flexible alternative for subclassing to expand functionality should be provided.

When using subclassing, different subclasses extend the class in different ways. But the extension is bound to the class at compile time and can not be changed at run-time.

What solutions are described by the Decorator design pattern?

Specify the Decorator object

• implements a transparently extended (<)> Component ) interface object by forwarding all requests to it and
• performs additional functions before/after forwarding requests.

This allows to work through various Decorator objects to extend the functionality of an object dynamically at run-time.
See also UML class and sequence diagram below.

Maps Decorator pattern

Intent

Decorator patterns can be used to extend (decorate) the functionality of certain objects statically, or in some cases at run-time, regardless of other instances of the same class, provided that some basis is done at design time. This is achieved by designing a new class of Decorator that wraps the original class. This package can be accomplished in the following sequence of steps:

1. The original Component subclass of the Decorator class (see UML diagram);
2. In the Decorator class, add the Components pointers as fields;
3. In the Decorator class, give Components to Decorator to initialize the Components pointer;
4. In the Decorator class, continue all Components methods to the Components pointer; and
5. In the ConcreteDecorator class, override any Components method whose behavior needs to be modified.

The pattern is designed so that multiple decorators can be stacked on top of each other, each time adding new functionality to the replaced method (s).

Note that the original class decorator and object share the same feature set. In the previous diagram, the operation method () is available in an unadorned and un decorated version.

Decorative features (for example, methods, properties, or other members) are usually determined by the interface, mixin (a.k.a. trait) or class inheritance shared by decorators and decorated objects. In the previous example, the Component class was inherited by ConcreteComponent and subclasses derived from Decorator .

Decorator pattern is an alternative to subclassing. Subclassing adds behavior at compile time, and changes affect all instances of the original class; decoration can provide new behavior at run time for the selected object.

This distinction becomes very important when there are some independent ways of extending functionality. In some object-oriented programming languages, classes can not be created at runtime, and it is usually impossible to predict, at design time, what combination of extensions is required. This means that a new class must be created for every possible combination. Conversely, decorators are objects, created at runtime, and can be combined on a per-use basis. I/O Stream Implementation from Java and.NET Framework incorporates decorator pattern.

src: 2.bp.blogspot.com

Motivation

For example, consider the window in the windowing system. To allow the scrolling of the contents of the window, one might want to add a horizontal or vertical scrollbar to it, as appropriate. Assume windows is represented by an instance of the Window interface, and assumes this class has no function to add a scrollbar. Someone can create a subclass of ScrollingWindow that provides it, or create a ScrollingWindowDecorator that adds this functionality to an existing Window object. At this point, the solution will be fine.

Now, assume one also wants the ability to add borders to the window. Again, the original class of Window does not have support. The ScrollingWindow subclass is now causing trouble, as it has effectively created a new window type. If someone wants to add border support to many but not all windows, somebody must create a subclass of WindowWithBorder and ScrollingWindowWithBorder etc. This problem gets worse with every new feature or subtype of the window to be added. For decorator solutions, we just create a new BorderedWindowDecorator - at runtime, we can decorate existing windows with ScrollingWindowDecorator or BorderedWindowDecorator or both, as we see fit. Note that if functionality needs to be added to all Windows, you can modify the base class and what will be done. On the other hand, sometimes (for example, using an external template) is not possible, legal, or convenient to modify a base class.

Notice, in the previous example, that the "SimpleWindow" and "WindowDecorator" classes implements the "Window" interface, which defines the "draw ()" method and the "getDescription ()" method, which is required in this scenario, in order to decorate the window control.

src: i.ytimg.com

Usage

Decorators allow to add or change interface behavior at run-time. Alternatively, the adapter can be used when the wrapper must respect the specific interface and must support polymorphic behavior, and Facade when the interface is easier or simpler to the underlying object desired.

src: www.cs.sjsu.edu

Structure

UML class and sequence diagram

In the above UML class diagram, the abstract class Decorator maintains a reference ( component ) to the decorated object ( Component ) and forwards all requests to it component.operation () ). This makes Decorator transparent (not visible) to client Component .

The subclass ( Decorator1 , Decorator2 ) applies additional behavior ( addBehavior () ) which should be added to Component (before/after forwarding a request for it) The sequence diagram shows the run-time interaction: The Client object works through the Decorator1 and Decorator2 objects to extend the functionality of the Component1 object.
The Client operation calls () on Decorator1 , which forwards the request to Decorator2 . Decorator2 performs addBehavior () after forwarding the request to Component1 and returns to Decorator1 , which does addBehavior ( ) and return to Client .

src: i.ytimg.com

Example

C

Two options are presented here, first a dynamic, runtime-composable decorator (having problems with calling functions decorated except for explicit proxies) and decorators using inheritance mixins.

Dynamic Decorator

Static Decorator (Mixin Inheritance)

This example shows a static Decorator implementation, which is possible because of the ability of C to inherit from template arguments.

Java

First example (window/scrolling scenario)

The following Java example illustrates the use of a decorator using the window/scrolling scenario.

The following classes contain decorators for all Window classes, including the own decorator class.

Here is a test program that creates a fully-decorated example of Window (that is, with vertical and horizontal scrollbars), and prints the description:

Below is a JUnit test class for Test Driven Development

The output of the program is "a simple window, including a vertical scrollbar, including a horizontal scrollbar". Notice how the getDescription method of both decorators first takes the decorated and decorated Window and adorns with the suffix.

The second example (coffee-making scenario)

The next Java example illustrates the use of a decorator using a coffee-making scenario. In this example, the scenario only covers costs and materials.

The following classes contain decorators for all classes Coffee , including their own decorator class..

Here is a test program that creates a fully-decorated Coffee (with milk and sprinkles), and calculates coffee costs and prints the ingredients:

The output of this program is given below:

  Cost: 1.0; Composition: Coffee  Cost: 1.5; Composition: Coffee, Milk  Cost: 1.7; Composition: Coffee, Milk, Sprinkles  

PHP

Python

The following Python example, taken from the Python Wiki - DecoratorPattern, shows us how the decorator pipeline dynamically adds a lot of behavior to an object:

Note:

Please do not confuse the Decorator Pattern (or the implementation of this design pattern in Python - for example above) with Python Decorators, a Python language feature. They are different things.

Kedua ke Python Wiki:

The Decorator Pattern is the pattern described in the Design Pattern Book. This is a way that seems to modify the behavior of an object, by attaching it inside a decoration object with a similar interface. This is not to be confused with Python Decorators, which is a feature of language to dynamically modify functions or classes.

Crystal

Output:

  Cost: 1.0; Composition: Coffee  Cost: 1.5; Composition: Coffee, Milk  Cost: 1.7; Composition: Coffee, Milk, Sprinkles  

src: 3.bp.blogspot.com

See also

• Composite pattern
• Adapter pattern
• Abstract class
• Abstract factory
• Aspect-oriented programming
• Objects that can not be changed

src: i.ytimg.com

References

src: 4.bp.blogspot.com

External links

• Patternator Pattern Implementation in Java
• Description of the decorator pattern from Portland Pattern Repository

Source of the article : Wikipedia