The Decorator Pattern attaches additional responsibilities to an object dynamically at runtime. Instead of using inheritance to add features from the top down, you wrap the original object inside a "decorator" object that adds the new behavior, like Russian nesting dolls.

The Problems It Solves

• The Feature Combination or Class Explosion: Prevents the nightmare of creating a rigid class for every possible combination (e.g., preventing the need for an EspressoWithMochaAndWhip class).
• Violating the Open-Closed Principle: It allows you to add entirely new behaviors to an object without ever touching or modifying the original object's source code.
• Stiff Inheritance Trees: It lets you mix and match features at runtime rather than locking an object's capabilities in at compile-time.

When to Use It

• You have a base object that needs features added, removed, or stacked on the fly.
• You have legacy code that you aren't allowed to modify, but you need to add new functionality to its objects.
• You are dealing with streams of data or UI components (like wrapping a raw data stream in a BufferedStream, then wrapping that in a GzipStream).

Step-by-Step Implementation

1. The Base Component (The Core Interface)

Everything must implement this so the wrappers and the base objects share the exact same type.

public abstract class Beverage{
    public abstract String getDescription();
    public abstract double cost();
}

2. The Concrete Component (The Inner Doll)

This is the base object that will eventually get wrapped. It hardcodes its own baseline identity and price.

public class Espresso extends Beverage{
    @Override
    public String getDescription(){
        return "Espresso";
    }

    @Override
    public double cost(){
        return 1.99;
    }
}

3. The Base Decorator (The Wrapper)

This intermediate class forces all condiments to be interchangeable with Beverages, while mandating they hold a reference to the thing they are wrapping.