Classification – Structural Pattern.
Intent – Providing extra responsibility to an object at run-time.
Discussion – Extending behavior of a class can be done statically by inheritance. But many times inheritance is not the best way to extend the behavior as it violates the Open Close Principle. Sub-classing also results in a more fragile code as and changes to super class may result in breaking all the subsequent sub classes. The alternative to inheritance is composition which allows the object to be wrapped by one or more decorator objects. Decorator objects are of same type as original objects and works on composition and delegation. Let see how decorator works using a class diagram.
Solution
decorator
Participants
- Component – Parent Interface for the class whose behavior is to be modified at runtime.
- ConcreteComponent – Main class whose behavior is to be modified at runtime.
- Decorator – Abstract class implementing Component and also contains an instance of component.
- ConcreteDecorator – Extends decorator. We need to have as many decorators as there are number of behavior.
Main points
- Decorators implement the same interface as the original object.
- They have an instance of original object.
- They implement the same method which needs extra responsibility.
- They are wrapper around the original objects.
- They are composed of original object and other decorators. They use composition to change the behavior.
- They provide a way to follow Open Close Principle.
Example.
Consider a pizza shop which sells pizza with many different kind of toppings. The toppings are customizable and final price of pizza will depend on topping that are used. Now one way to calculate the cost of each combination will be to have a subclass for each of the pizza combination and implement the cost method for each combination. The drawbacks for above scenario.
- Lets say there are 20 combinations. Then combinations of all the components will be huge. So we have to write staggering number of classes.
- If someone wants double topping of a particular components the number of combination will become even more.
- Adding one new component will result in addition of many more classes.
Thus we see that sub-classing here is not an option. Let see how we can use Decorator for solving this.
- Create a Pizza interface with method cost() and description(aka component)
- Implement Pizza interface lets say we have Pan Pizza and classic hand tossed pizza. (aka ConcreteComponent)
- Create a PizzaDecorator abstract class which implements Pizza. Add a instance variable of type Pizza. (aka decorator)
- Extend PizzaDecorator with as many toppings you have and implement the cost and description methods (aka concrete decorator).
Let check out the code for more coherency.
Component
public interface Pizza {
public double cost();
public String description();
}
ConcreteComponents
public class ClassicPizza implements Pizza {
@Override
public double cost() {
return 175;
}
@Override
public String description() {
return "This is classic hand tossed pizza";
}
}
public class PanPizza implements Pizza {
@Override
public double cost() {
return 200;
}
@Override
public String description() {
return "This is pan pizza";
}
}
Decorator
public abstract class Toppings implements Pizza{
public Pizza pizza;
}
ConcreteDecorator
public class Paneer extends Toppings{
public Paneer(Pizza pizza){
this.pizza = pizza;
}
@Override
public double cost() {
return pizza.cost() + 50;
}
@Override
public String description() {
return pizza.description() + " paneer";
}
}
public class Cheese extends Toppings {
public Cheese(Pizza pizza){
this.pizza = pizza;
}
public double cost() {
return pizza.cost() + 30;
}
@Override
public String description() {
return pizza.description() + " cheese ";
}
}
public class Onion extends Toppings {
public Onion(Pizza pizza){
this.pizza = pizza;
}
public double cost() {
return pizza.cost() + 15;
}
@Override
public String description() {
return pizza.description() + " onion ";
}
}
public class Chicken extends Toppings{
public Chicken(Pizza pizza){
this.pizza = pizza;
}
@Override
public double cost() {
return pizza.cost() + 50;
}
@Override
public String description() {
return pizza.description() + " chicken";
}
}
So here we are, we have all the components to create our own pizza as per our wish. Check out how the cost and description method of pizza are modified at runtime in our concrete decorators. So now lets see how our PizzaMachine looks
public static void main(String[] args){
// i want classic pizza
Pizza pizza = new ClassicPizza();
//want double dose of cheese on it
Cheese cheese = new Cheese(pizza);
cheese = new Cheese(cheese);
//want some chicken on it.
Chicken chicken = new Chicken(cheese);
//want some onion on it
Onion onion = new Onion(chicken);
System.out.println("Your pizza is ready");
System.out.println("You have ordered a " + onion.description() + " pizza");
System.out.println("Price of your pizza is : " + onion.cost());
}
}
So here we are, we have successfully created a PizzaMachine which calculates cost of Pizzas at run-time. We attained this by wrapping/decorating a Pizza Objects with all the toppings we required.
Famous example
In java IO streams use decorator patterns. We have a base class InputStream which is an abstract class. Other classes FileInputStream, BufferedStream etc extends this class and keeps an instance of InputStream.
References
