Dynamic Behavior with the Decorator Pattern

Hello! Welcome back to our module on Structural Design Patterns.

In our previous lesson, we explored the Adapter pattern, which acts as a bridge to make incompatible interfaces work together. We saw how it can cleanly integrate legacy code or third-party libraries without modifying existing client code.

Today, we'll examine another powerful structural pattern. Your learning outcome is to apply the Decorator pattern to add behavior to objects dynamically.

Where the Adapter pattern changes an object's interface, the Decorator pattern enriches an object's functionality. It allows you to add new responsibilities to an object flexibly and dynamically, without altering its underlying class or the interfaces it implements. This is a key tool for creating scalable and maintainable systems.

The Problem: When Inheritance Becomes a Burden

Imagine you're building a notification system. The initial requirement is to send email notifications. Simple enough. But soon, product managers want to add notifications via SMS, WhatsApp, and Facebook. A user might want to receive only an email, another might want email and SMS, and a third might want all four.

If you were to use inheritance to solve this, you'd quickly run into a "class explosion." You'd need classes like EmailAndSmsNotifier, EmailAndWhatsAppNotifier, EmailSmsAndWhatsAppNotifier, and so on. This approach is rigid, unmanageable, and violates the Open/Closed Principle.

To see this problem in action, let's watch a short segment from a video by Geekific.

This is precisely the kind of inflexible design we want to avoid. The Decorator pattern offers a much more elegant solution.

The Decorator Solution: Wrapping Objects

The Decorator pattern solves this by letting you attach new behaviors to an object by placing it inside a special "wrapper" object. You can have many wrappers, each adding a new responsibility. The key is that both the original object and all the wrappers share the same interface.

Think of ordering a coffee or a pizza. You start with a base item (a plain coffee or a margherita pizza) and then "decorate" it with extras like milk, sugar, cheese, or olives. Each extra adds to the cost and description without changing what a "pizza" or "coffee" fundamentally is.

Let's look at another analogy, this time with a customizable burger, to solidify this core concept.

Structure of the Decorator Pattern

The pattern has four main participants that work together to achieve this "wrapping" effect.

1. Component: An interface or abstract class that defines the methods that will be implemented by both the concrete components and the decorators. (e.g., Pizza, Coffee, Notifier).
2. Concrete Component: The base object to which we want to add new functionality. It implements the Component interface. (e.g., MargheritaPizza, PlainCoffee, EmailNotifier).
3. Decorator: An abstract class that also implements the Component interface. It holds a reference (using composition) to a Component object. This is the "wrapper".
4. Concrete Decorator: These are the classes that contain the additional responsibilities. They extend the abstract Decorator and add their own behavior before or after delegating the call to the wrapped Component object. (e.g., CheeseTopping, MilkDecorator, SmsDecorator).

This UML diagram visualizes the structure using the coffee example:

Java Implementation Walkthrough

Now, let's see how this structure is implemented in Java. We'll continue with the burger example, which clearly demonstrates how to calculate costs and build descriptions by chaining decorators.

As you saw, the client code can mix and match decorators at runtime to create different combinations. This is possible because both the base ZingerBurger and the decorators (ExtraCheeseBurger, ExtraMayoBurger) are treated as the same type (Burger) through polymorphism.

How the Call Stack Works

When you call a method on the outermost decorator, it creates a chain of calls that goes all the way down to the original object.

Let's use a pizza example to trace the execution. If you have an object created like this:
Pizza pizza = new OliveTopping(new CheeseTopping(new MargheritaPizza()));

A call to pizza.getCost() would work as follows:

1. OliveTopping.getCost() is called. It returns 30.0 + pizza.getCost().
2. To resolve pizza.getCost(), it calls CheeseTopping.getCost() on the wrapped object.
3. CheeseTopping.getCost() returns 50.0 + pizza.getCost().
4. To resolve this pizza.getCost(), it calls MargheritaPizza.getCost() on the object it wraps.
5. MargheritaPizza.getCost() returns the base cost, 200.0.
6. The calls unwind: 50.0 + 200.0 = 250.0.
7. And again: 30.0 + 250.0 = 280.0.

public interface Text {
    String getContent();
}

public class PlainText implements Text {
    private String content;

    public PlainText(String content) {
        this.content = content;
    }

    @Override
    public String getContent() {
        return content;
    }
}

Text myText = new PlainText("Hello World");
System.out.println(myText.getContent()); // Output: Hello World

Text boldText = new BoldText(myText);
System.out.println(boldText.getContent()); // Output: <b>Hello World</b>

Advantages and When to Use It

The Decorator pattern is particularly useful because it aligns perfectly with the Open/Closed Principle: you can extend an object's behavior without modifying its source code.

A classic example from the Java Development Kit (JDK) that you've likely used is the java.io package. A FileInputStream (a concrete component) can be wrapped by a BufferedInputStream (a decorator that adds buffering) which can then be wrapped by a DataInputStream (a decorator that adds methods for reading primitive data types).

new DataInputStream(new BufferedInputStream(new FileInputStream("myFile.txt")));

This is the Decorator pattern in action, allowing you to compose I/O behaviors flexibly.

Conclusion

The Decorator pattern provides a flexible alternative to subclassing for extending functionality. By wrapping objects, you can add new behaviors at runtime, combine them in various ways, and adhere to core design principles.

Key Takeaways:

• Purpose: To add responsibilities to objects dynamically and transparently.
• Structure: It uses a chain of "wrapper" objects (Decorators) around a core "wrapped" object (Component), all sharing a common interface.
• Mechanism: It relies on composition and delegation. Each decorator adds its behavior and then delegates the call to the object it wraps.
• Primary Benefit: It follows the Open/Closed Principle, allowing for extension without modification, and avoids the "class explosion" problem of using inheritance for feature combinations.

In our next lesson, we will look at the Facade pattern. While a Decorator adds behavior to an object, a Facade provides a simplified, high-level interface to a complex subsystem. It's about reducing complexity, not adding functionality.