1. Decorator Pattern
Richard Gesick

2. Pattern Overview
The Decorator pattern provides a flexible alternative to subclassing by attaching additional responsibilities to an object dynamically, by using an instance of a subclass of the original class that delegates operations to the original object
This pattern type falls into the Structural Patterns category and deals with objects.

3. Structure -- UML Construction
The ConcreteComponent is the object that can be decorated
An instance variable is included in the ConcreteDecorator for the object that it will decorate.

4. As seen in the diagram each component can be used on its own or wrapped by a decorator. 
Decorators extend the state of the component. 
Additionally they implement the same interface or abstract class as the component they are going to decorate

6. Attach additional responsibilities to an object dynamically.
Decorators provide a flexible alternative to subclassing for extended functionality.

7. Applicability
Need to add responsibilities to objects dynamically and transparently
Need to withdraw responsibilities
Need to support large combinations of responsibilities without a class explosion
When extension by subclassing is impractical or impossible

8. Consequences More flexible than static inheritance
Avoids feature-laden classes high up in the hierarchy
A decorator and its component aren't identical
Decorators can be an effective, less-confusing and more easily maintainable substitute for multiple-inheritance.

9. Lots of little objects!
Functionality of a class can be extended knowing only its interface; source is not always required.  Therefore, the class is closed to modification, but open to extension.
Decorators allow more flexibility to code by avoiding extending your class hierarchy just to support a characteristic.
Resources are used as they are needed since run-time objects are created.

10. The Open-Closed Principle
Design Principle: Classes should be open for extension, but closed for modification. 
Our goal is to allow classes to be easily extended to incorporate new behavior without modifying existing code.

11. This gives us designs that are resilient to change and flexible enough to take on new functionality to meet changing requirements. 
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.