Decorator Pattern: Attaches additional responsibilities to an object dynamically and
provide a flexible alternative to subclassing for extending
functionality.
Since programming schemes using inheritance often result in class explosion, rigid design or adding functionality to the base class that is not appropriate for other subclasses, another design pattern may be used - the decorator pattern. This pattern follows the open-closed principle (Check out all other design principles in this post: OO principles):
Design Principle 5: Classes should be closed to change, but open to extensions. This allows to incorporate new behavior without changing existing code. This principles seems like a contradiction, but there are techniques for allowing code to be extended without direct modification.
Still be careful when choosing the areas of code that need to be extended. Applying the open-closed principle everywhere is wasteful, unnecessary, and can lead to complex, hard to understand code.
Example: Imagine a pizza shop having different types of dough and various toppings (cheese, salami, ham, ...). The pizza shop wants to be able to combine its different types of dough with all their toppings (dynamically).
The decorator pattern uses 'decorator' objects to decorate/wrap another object. This is possible since these 'decorator' objects have the same supertype as the objects they decorate. The decorator adds its own behavior either before and/or after delegating to the object it decorates to do the rest of the job.
To implement the decorator pattern for our pizza shop, the different types of dough serve as our concrete components, while available toppings serve as our decorators. Each decorator holds (wraps/has-a) component, an instance variable that holds a reference to a component.
We are therefore able to decorate our doughs dynamically at run time with as many toppings as we like. By using a combination of inheritance (subclassing) and composition this pattern gains a lot more flexibility at run time. Decorators are meant to add behavior to an object they wrap.
The decorator pattern is often used in combination with other patterns, like Factory and Builder. This way the creation of concrete components with its decorators is 'well encapsulated' and does not lead to problems like increased chance of coding errors due to adding a lot of small classes, occasionally resulting in a less straightforward design (for other developers to understand)
Example: Imagine a pizza shop having different types of dough and various toppings (cheese, salami, ham, ...). The pizza shop wants to be able to combine its different types of dough with all their toppings (dynamically).
The decorator pattern uses 'decorator' objects to decorate/wrap another object. This is possible since these 'decorator' objects have the same supertype as the objects they decorate. The decorator adds its own behavior either before and/or after delegating to the object it decorates to do the rest of the job.
To implement the decorator pattern for our pizza shop, the different types of dough serve as our concrete components, while available toppings serve as our decorators. Each decorator holds (wraps/has-a) component, an instance variable that holds a reference to a component.
 |
| Decorator uml (wikipedia) |
The decorator pattern is often used in combination with other patterns, like Factory and Builder. This way the creation of concrete components with its decorators is 'well encapsulated' and does not lead to problems like increased chance of coding errors due to adding a lot of small classes, occasionally resulting in a less straightforward design (for other developers to understand)
No comments:
Post a Comment