Decorator (structural pattern) allows to extend the functionality or modify the state of an existing object without changing its structure during the lifecycle program. It is an alternative to ‘inheritance’ which happens during compilation unlike to
Decorator. Grants the rules of
OCP - open / closed and
SRP - single responsibility. This pattern is a kind of
Wrapper for an existing class. An object of base class can be extended by several decorators, thus enabling the creation of many variants of behavior without interfering with the structure of the extended class. This process applies to one object, not all instances of the class. As a result, the structure of classes and inheritance becomes transparent, and the project is open and flexible for future modifications and new extensions.
The risk of using
Decorator can be a reduntant number of classes. It could be necessary to consider whether the implementation of this template is indeed the best way to solve the problem.
Decorator is often used in the implementation of interface controls -
View classes. It can be found also in
I / O streams in Java. It is implemented where there is a need to create multiple behaviors for objects of the same type depending on where they occur and the use of inheritance is too expensive or unpredictable. An example of this is the process of taking an order for a given product with the option of adding ingredients to it. Using
Decorator for 5 extensions, just create 5 Decorators. Using “inheritance” (to provide the same number of types) it would be necessary to create 31 classes!
The basic classes of the components
Component2, etc. and the base class of the decorator
Decorator extend the abstract class or implement the common interface
Decorator takes a
Component class object as a parameter. Decorator classes
Decorator2 extend the base
Decorator class. Decorators implement a new functions and extend the behavior of the
Component base class methods.
The following listing shows example of implementations of the
This implemented pattern can be used in the following way.
The application is a sketch of the avatar building process (
Component) in a computer game. The player develops his character at various stages of the game by gaining strength points and new skills (
Decorator). Interactions between characters, such as combat, depend on the strength of their profiles. This profile changes over time, and thanks to the variety of skills acquired, the world of characters is diverse. The following listing shows the basic components of the pattern.
The hero gains additional strength points, powers, and also changes the way of fighting thanks to the help of the following decorators (profiles).
The scheme of acquiring new skills and interactions between characters (spread over time) could look like the following list.
Due to the simplicity of the pattern, its specificity and low cost of implementation, the use of libraries implementing the
Decorator pattern is pointless. The most common use in
Android is extending views behavior.
Decor is an example of a library that makes it easy to add decorators to