Understanding Design Patterns
This article is part of series in Understanding Design Patterns:
- Understanding Design Patterns - Simple Factory
- Understanding Design Patterns - Factory Method
- Understanding Design Patterns - Abstract Factory
- Understanding Design Patterns - Singleton
- Understanding Design Patterns - Observer
- Understanding Design Patterns - Command
- Understanding Design Patterns - Template Method
- Understanding Design Patterns - Strategy
- Understanding Design Patterns - Iterator
- Understanding Design Patterns - Composite
- Understanding Design Patterns - Decorator
- Understanding Design Patterns - State
- Understanding Design Patterns - Adapter
- Understanding Design Patterns - Facade
Attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
Coffee is a constant in almost everyone's day. The caffeine shot it gives to jump-start the day is something that most people cannot do without. Waking up to the smell of coffee brewing in the kitchen is enough to perk up anyone's day. The aroma, the taste, and the energy boost you get after a cup of coffee has made this dark drink an indispensible part of our mornings. No wonder why coffee shops like Starbucks and the Coffee Bean are doing so well in their business.
A cup of black coffee is served as a beverage without cream or milk, and it looks like this in code:
However, black coffee is not really a popular choice because of its overpowering bitter taste. Most people prefer to have milk in their coffee; this not only subdues the strong flavor of the coffee but also gives a sweet mellow flavor to the drink.
To create it in code, what we would normally do is use subclassing. Inheritance seems to be a natural choice:
Now that we've added milk to our coffee, we realize that its not the only add-on we put in our drink. Some people like sugar, some prefer cream and sugar and some want milk and sugar. What if we need to create all the possible varieties? Supposing cream, milk, and sugar are the three available condiments, then there are six possible ways to make a cup of coffee. For every coffee variant, we will need to create a subclass:
In reality, there are even more variants. Choices can be as simple as less milk or less sugar, but the impact of those variations need to be taken note of. Now when you think about the add-ons like cocoa powder, cinnamon and other flavors that can enhance coffee, this can be a maintenance nightmare.
We will need a better solution. This is when the Decorator Pattern comes in handy. We will create decorator classes that adds condiments to the coffee objects. First, let us create a decorator class that adds milk to a coffee:
Note that, the WithMilkDecorator class still implements Beverage interface as Coffee class does.
Let us also create two other decorators:
Now, instead of having six subclasses of Coffee, we will have three decorators and they will achieve the same goal that we need. For example, to make a cup of coffee with milk and sugar:
Clearly, by using the Decorator Pattern, we create less classes to maintain and avoid introducing bugs with more codes. What's more, Decorator Pattern adds additional feature to the wrapper class at run time, so it is flexible to add/remove features compared to inheritance via subclassing.
In our example, the Decorator Pattern attaches additional responsibilities (milk condiment, sugar condiment and cream condiment) to an object (Coffee object) dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
Hopefully this simple tutorial helped you with your development.
If you like our post, please follow us on Twitter and help spread the word. We need your support to continue.
If you have questions or find our mistakes in above tutorial, do leave a comment below to let us know.