phani kumar - decorator pattern
DESCRIPTION
Phani Kumar - Decorator PatternTRANSCRIPT
Decorator Pattern
By Phani
• Intent
• Motivation
• Decorator Implementation
• Disadvantages
Agenda
The intent of The Decorator pattern referring to GoF book
"Attach additional responsibilities to an object dynamically. Decorators provide a flexible alterative to subclassing for extending functionality."
Decorators are also known as “wrappers” , because a decorator wraps itself around another object.
Today we will discuss why the Decorator design pattern provides a flexible alternative to subclassing as it demonstrates why subclassing can be dangerous.
Intent
Motivation
Example – Coffee
class decorator
Beverage
~ descriptio n: String
+ cost() : double+ getDescriptio n() : String
DarkRoast
+ cost() : double+ DarkRoast()
Dec af
+ cost() : double+ Decaf()
Espresso
+ cost() : double+ Espresso()
House Blend
+ cost() : double+ HouseBlend()
Example – CoffeeHow the design would look by adding several condiments like steamed milk, chocolate and mocha
class decorator
Beverage
~ descriptio n: String
+ cost() : double+ getDescriptio n() : String
DarkRoast
+ cost() : double+ DarkRoast()
Dec af
+ cost() : double+ Decaf()
Espresso
+ cost() : double+ Espresso()
EspressoWithSteame dMilkAndChocolate
+ cost() : double
EspressoWithSteamedMilk
+ cost() : double
EspressoWithChocolate
+ cost() : double
DarkRoastWithSteamedMilkAndChocolate
+ cost() : double
DarkRoastWithSteamedMilk
+ cost() : double+ DarkRoastWithSteamedMilk()
DarkRoastWithChocolate
+ cost() : double
House Blend
+ cost() : double+ HouseBlend()
Example – CoffeeModifying above design to avoid class explosion
class decorator
Beverage
~ chocolate: boolean~ descriptio n: String~ milk: boolean~ mocha: boolean
+ cost() : double+ getDescriptio n() : String+ isChocolate() : boolean+ isMilk() : boolean+ isMocha() : boolean+ setChocolate(boolean) : void+ setDescription(String) : void+ setMilk(boolean) : void+ setMocha(boolean) : void
DarkRoast
+ cost() : double+ DarkRoast()
Dec af
+ cost() : double+ Decaf()
Espresso
+ cost() : double+ Espresso()DarkRoastWithSteamedMilk
+ cost() : double+ DarkRoastWithSteamedMilk()
House Blend
+ cost() : double+ HouseBlend()
Disadvantages of above design•Based on the assumption that condiments are included as part of the cost of coffee.
– Price changes to condiments will force a change to all classes.
• Additional condiments (like sugar) will force code changes into all existing classes.
• All beverages will inherit all condiments regardless if required due to the inheritance.
•What if customer needs multiple sugars or double the chocolate?
The Open – Closed PrincipleDesign Principle : Classes should be open for extension, but closed for modification.
The code should be designed to allow classes to be easily extended to incorporate new behavior (such as adding condiments) without modifying the existing code (such as Espresso).
Therefore the design is resilient to change and flexible enough to take on new functionality to meet changing requirements.
cost()
Meet The Decorator
Constructing the above example with the Decorator pattern.
cost()
cost()
cost()
Meet The Decorator
cost()
cost()
UML for Decorator
What we know so far…
• Decorators have the same subtype as the objects they decorate.- public class Espresso extends Beverage- public abstract class CondimentDecorator extends Beverage
• You can use one or more decorators (such as a variety of condiments) to wrap an object.
• Given that the decorator has the same super type as the object it decorates, An enhanced decorated object can now be used in place of the original object.
- Beverage espresso = new DarkRoast();- Beverage mocha = new SteamedMilk(espresso);- Beverage chocolate = new Chocolate(mocha);
• Objects can be decorated at anytime, so we can decorate objects dynamically at runtime with as many decorators as we like. Such as:
public double cost() {return beverage.cost() + 1.5;
}
Coffee Design with Decoratorclass decorator
Beverage
~ descriptio n: String
+ cost() : double+ getDescriptio n() : String
DarkRoast
+ cost() : double+ DarkRoast()
Dec af
+ cost() : double+ Decaf()
Espresso
+ cost() : double+ Espresso()
SteamedMilk
+ cost() : double+ getDescriptio n() : String
Moc ha
+ cost() : double+ getDescriptio n() : String
CondimentDecorator
+ getDescription() : String
Chocolate
+ cost() : double+ getDescriptio n() : String
House Blend
+ cost() : double+ HouseBlend()
Real World Decorators: Java I/Oclass io
«concrete decorator»BufferedInputStream
«concrete component»ByteArrayInputStream
«concrete decorator»DataInputStream
«concrete component»FileInputStream
«abstract decorator»FilterInputStream
«abstarct component»InputStream
«concrete decorator»LIneNumberInputStream
«concrete decorator»PushbackInputStream
«concrete component»StringBuffer InputStream
Disadvantages of Decorator
• Designs using this pattern often result in a larger number of smaller classes that can be overwhelming to a developer trying to use the Decorator-based API.
• Introducing decorators can increase the complexity of code needed to instantiate the component. Once you’ve got decorators, you’ve got to not only instantiate the component, but also wrap it with who knows how many decorators.