The document discusses the Decorator design pattern, which provides a flexible alternative to subclassing by allowing additional responsibilities to be attached to an object dynamically at runtime through the use of wrapper objects known as decorators. It provides an example of using decorators to modify a coffee order by adding condiments like milk and chocolate without exploding the number of classes. The key advantages of the Decorator pattern are that it allows extending functionality without modifying existing classes and supports adding multiple decorators to an object dynamically at runtime. Some disadvantages are that it can result in more smaller classes and increase complexity when instantiating decorated components.

1. Decorator Pattern By Phani

2. Intent Motivation Decorator Implementation Disadvantages Agenda

3. 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

4. Motivation

5. Example – Coffee

6. Example – Coffee How the design would look by adding several condiments like steamed milk, chocolate and mocha

7. Example – Coffee Modifying above design to avoid class explosion

8. 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?

9. The Open – Closed Principle Design 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.

10. Meet The Decorator cost() Constructing the above example with the Decorator pattern. Espresso cost() Espresso Mocha cost()

11. Meet The Decorator cost() cost() Espresso Mocha Chocolate cost()

12. UML for Decorator

13. 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; }

14. Coffee Design with Decorator

15. Real World Decorators: Java I/O

16. 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.