Decorator pattern
The Decorator pattern is a structural design pattern in object-oriented programming that enables the attachment of additional responsibilities to an individual object dynamically and transparently, without altering the object's class or affecting other instances of the same class.[1] It achieves this by wrapping the original object with one or more decorator objects that conform to the same interface, delegating method calls to the wrapped object while injecting new behaviors before or after the delegation.[2] This approach provides a flexible alternative to subclassing, allowing functionality to be extended through composition rather than inheritance, and supports the open-closed principle by keeping original classes closed to modification while open to extension.[3]
First described in the seminal 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides—commonly known as the Gang of Four (GoF) book—the Decorator pattern is one of 23 classic patterns classified into creational, structural, and behavioral categories.[3] As a structural pattern, it focuses on composing classes and objects to form larger structures while keeping them flexible, particularly useful in scenarios where responsibilities need to be added or removed at runtime without creating an explosion of subclasses for every possible combination of features.[1] The pattern's motivation often arises from the need to enhance existing objects—such as adding visual effects to graphical components or logging to streams—without modifying their core implementation, thereby promoting reusability and maintainability.[2]
The structure of the Decorator pattern typically involves four key participants: a Component, which is an abstract interface or class defining the operations to be enhanced; a ConcreteComponent, providing the basic implementation of the Component; a Decorator, an abstract class that implements the Component interface and maintains a reference to a Component instance for wrapping; and one or more ConcreteDecorators, which extend the Decorator to add specific behaviors, such as modifying return values or performing side effects.[2] Clients interact with decorators as if they were the original component, enabling recursive wrapping where multiple decorators can be layered around a single object to build complex functionality incrementally.[1]
Among its notable consequences, the pattern avoids the rigidity and class proliferation of static inheritance hierarchies, allowing dynamic attachment and detachment of responsibilities while preserving type compatibility through the shared interface.[1] However, it introduces overhead from numerous small classes and potential complexity in managing long chains of decorators, requiring careful implementation to ensure efficiency and transparency to clients.[1] The Decorator pattern is applicable in domains like input/output streams, user interface frameworks, and service layers, where extensible behavior is essential, and it often collaborates with patterns like Composite for handling object trees or Strategy for varying algorithms.[4]
Fundamentals
Overview
The Decorator pattern is a structural design pattern that enables the dynamic attachment of new behaviors to individual objects by wrapping them in specialized wrapper objects, without altering the underlying object's code or affecting other instances of the same class.[4] This approach relies on composition over inheritance, allowing functionality to be extended at runtime through a chain of decorators that each add incremental responsibilities.[4]
Introduced in the seminal 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides—commonly known as the Gang of Four (GoF) book—the Decorator pattern is one of the 23 foundational patterns categorized into creational, structural, and behavioral types.[5] It exemplifies object-oriented design principles by promoting flexibility in system evolution.[5]
A core strength of the Decorator pattern lies in its adherence to the open-closed principle, which states that software entities should be open for extension but closed for modification; decorators achieve this by layering new features externally rather than subclassing, thus avoiding code changes to core components.[4] Key benefits include enhanced flexibility for combining behaviors dynamically and prevention of class proliferation that often arises from extensive subclassing hierarchies.[4]
Intent
The intent of the Decorator pattern, as defined by Gamma et al. in their seminal book Design Patterns: Elements of Reusable Object-Oriented Software, is to "attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality." This structural pattern enables the dynamic composition of behaviors by wrapping objects in decorator classes that implement the same interface as the original, allowing new features to be added or removed at runtime without altering the core object's code.[4]
By facilitating such extensions through composition rather than inheritance, the Decorator pattern addresses the need to enhance object functionality while preserving the integrity of existing classes, aligning with principles like open-closed that favor extensibility without modification.[4] It mitigates the rigidity of static inheritance hierarchies, where adding multiple independent features—such as different combinations of logging, caching, or validation—would otherwise require modifying base classes or generating an unwieldy number of subclasses.
A key limitation of subclassing that the Decorator pattern overcomes is the potential for combinatorial explosion: for n distinct features, subclassing could necessitate up to 2n classes to cover all possible combinations, leading to code bloat and maintenance challenges.[4] In contrast, decorators allow these behaviors to be layered selectively and dynamically, promoting flexibility and reducing class proliferation.[4]
Motivation
The Decorator pattern emerges as a solution to the challenges posed by excessive subclassing in object-oriented design, where extending functionality through inheritance leads to a proliferation of subclasses for every possible combination of behaviors. For example, consider a basic window component in a graphical interface that requires optional features such as borders, scrollbars, or resizing capabilities; creating subclasses for each permutation—such as a "Scrolled Bordered Window" or "Resized Scrollbar Window"—results in an exponential growth of classes, making the system rigid, difficult to maintain, and prone to code duplication. This approach violates the open-closed principle by necessitating modifications to the inheritance hierarchy for new extensions, as the number of subclasses scales poorly with added features.[6]
To overcome this, the Decorator pattern enables the dynamic attachment of additional responsibilities to objects at runtime, allowing behaviors to be added or removed based on contextual needs without altering the underlying class structure or requiring recompilation. This flexibility is particularly valuable in scenarios where requirements evolve unpredictably, such as user interfaces or configurable services, where static inheritance would otherwise lock in behaviors prematurely. By wrapping objects with decorator layers, the pattern supports transparent extension while preserving the original object's interface and identity, facilitating modular composition over rigid hierarchies.[6][7]
Illustrative scenarios highlight this motivation effectively. In a window system, a simple window can be successively decorated with a scrollbar (adding vertical navigation) and then a border (adding visual framing), each decorator delegating calls to the inner component while injecting its own logic, thus stacking enhancements without subclass explosion. Similarly, in a beverage ordering system, a base coffee object remains unchanged but can be wrapped with decorators for add-ons like milk or whipped cream, allowing arbitrary flavor combinations at runtime and avoiding the need for subclasses like "MochaWithMilkAndSugar." These examples demonstrate how the pattern keeps the core object intact while enabling stackable, context-dependent augmentations.[6][8]
While powerful, the Decorator pattern introduces trade-offs, including added indirection through multiple layers of wrapping, which can obscure object relationships and complicate debugging or equality checks, though it ultimately fosters more modular and extensible designs compared to inheritance-heavy alternatives.[7]
Structure and Design
Core Components
The Decorator pattern consists of four primary classes that enable the dynamic addition of responsibilities to objects through wrapping. The Component serves as an abstract base class or interface that declares the core operations shared by all objects, including both concrete components and decorators; for instance, it might define a single method like operation() to represent the essential behavior.[9][10]
The ConcreteComponent is a specific class that implements the Component interface, providing the basic functionality without any additional embellishments; it represents the original object that can later be wrapped to extend its behavior.[9][10]
The Decorator is an abstract class that implements the Component interface and maintains a reference to a Component object, acting as a wrapper that delegates calls to the wrapped instance while allowing subclasses to add new behavior; this structure uses composition to hold the component rather than inheriting directly from it, promoting flexibility over rigid subclassing.[9][10]
ConcreteDecorator classes extend the Decorator by implementing specific enhancements, such as adding actions before or after delegating to the wrapped Component; multiple ConcreteDecorators can be stacked recursively to compose complex behaviors dynamically.[9][10]
This composition-based approach, where each Decorator holds a reference to a Component, enables runtime extension without modifying the original class hierarchy, contrasting with inheritance which would require predefined subclasses for each combination.[9][10]
A typical pseudocode outline for delegation in a ConcreteDecorator might appear as follows:
class ConcreteDecorator extends Decorator {
operation() {
super.operation(); // Delegate to wrapped Component
addedBehavior(); // Add new responsibility
}
addedBehavior() {
// Specific enhancement logic
}
}
class ConcreteDecorator extends Decorator {
operation() {
super.operation(); // Delegate to wrapped Component
addedBehavior(); // Add new responsibility
}
addedBehavior() {
// Specific enhancement logic
}
}
This delegation ensures that the wrapped object's core operation is preserved while new functionality is seamlessly integrated.[9][10]
UML Diagrams
The UML class diagram for the Decorator pattern depicts the static relationships among its key classes, providing a visual representation of how responsibilities are added through composition and inheritance. At the core is the Component, typically modeled as an abstract class or interface that declares the operation() method, serving as the common interface for objects that may be decorated. The ConcreteComponent class realizes this interface by implementing the basic operation() functionality without any additional behavior. The Decorator abstract class also realizes the Component interface and includes a private reference to a Component instance, enabling it to wrap and delegate calls to the wrapped object. One or more ConcreteDecorator classes extend the Decorator, each adding specific enhancements to the operation() method, such as pre- or post-processing around the delegated call.[9][11]
In the diagram, generalization arrows (solid lines with hollow triangle arrowheads) indicate inheritance: from ConcreteComponent to Component, and from Decorator (and its subclasses) to Component, emphasizing that all participants conform to the same interface. A composition association (solid line with filled diamond at the Decorator end) connects Decorator to Component, representing the "has-a" relationship where each decorator instance holds exactly one component instance; multiplicity is denoted as 1 on both ends, signifying a one-to-one wrapping. This structure allows transparent substitution of decorated objects for basic ones in client code.[9]
The UML sequence diagram illustrates the runtime dynamics of the Decorator pattern, focusing on how a client interacts with a chain of decorators to invoke an operation. Vertical lifelines represent participants: the Client at the top left, followed by instances of ConcreteDecoratorA, ConcreteDecoratorB (or multiple stacked decorators), and finally the ConcreteComponent at the bottom. The diagram flows from top to bottom, starting with the Client sending a operation() message to the outermost ConcreteDecoratorA, which performs any added behavior (e.g., prefix actions) before forwarding the same message to its wrapped ConcreteDecoratorB via delegation. This delegation continues through the chain until reaching the ConcreteComponent, which executes the core operation() and returns the result upward. Each decorator then appends its specific post-processing (e.g., suffix actions) on the return path, effectively layering enhancements without altering the client's interaction.[9][12]
Key elements in the sequence diagram include synchronous messages (solid arrows with open arrowheads) for the operation() calls and returns (dashed arrows with open arrowheads), highlighting the recursive delegation. Activation bars (thin rectangles on lifelines) show the duration of method execution at each level, underscoring the transparent propagation through the wrapper chain. No loops or alternatives are typically present, as the pattern assumes linear stacking.[9][12]
A common variation in UML diagrams for the Decorator pattern extends the class diagram to explicitly show multiple ConcreteDecorators in a chain via object diagrams, where instances are linked by composition arrows forming a linear sequence (e.g., ConcreteDecoratorB composes ConcreteDecoratorA, which composes ConcreteComponent). This optional representation emphasizes the pattern's support for stacking multiple wrappers dynamically, without predefined limits on chain length. The sequence diagram can similarly vary to include more lifelines for longer chains, demonstrating scalability in delegation.[9][13]
Use Cases and Applications
Real-World Scenarios
The Decorator pattern finds extensive application in graphical user interface (GUI) frameworks, where it enables the addition of visual enhancements such as borders, scrollbars, and frames to basic window components without requiring exhaustive subclassing for every possible combination. In the seminal work by Gamma et al., the pattern is exemplified through a window interface system, where concrete decorators like ScrollbarDecorator and BorderDecorator wrap a Window component to dynamically compose interfaces at runtime, avoiding the rigidity of static inheritance hierarchies. This design is reflected in Java's Swing framework, which employs the Decorator pattern to add borders and other visual enhancements to components dynamically.[14]
In stream processing for input/output operations, the Decorator pattern is a cornerstone for layering functionalities like buffering, encryption, and compression onto base streams. Java's I/O API implements this through subclasses of InputStream and OutputStream, such as BufferedInputStream, which wraps another InputStream to add buffering while delegating core read operations, and GZIPInputStream, which adds decompression capabilities. This chaining mechanism permits efficient, modular extensions to handle diverse data processing needs in applications ranging from file handling to network communications.[15]
For API extensions in web services, the Decorator pattern supports the transparent addition of cross-cutting concerns, such as logging, caching, or authentication, to service invocations without altering the underlying business logic. In Java EE environments, this is demonstrated by servlet request decorators that wrap HttpServletRequest objects to inject behaviors like content compression or security validation, as outlined in patterns for enhancing servlet filters. Similarly, in .NET microservices, decorators applied via dependency injection pipelines allow behaviors like caching or telemetry to be stacked around application services, enhancing maintainability in distributed systems.[3][16]
In game development, the Decorator pattern enhances entities like characters or items by dynamically attaching temporary abilities, equipment effects, or buffs, facilitating runtime customization in complex simulations. For instance, a base Player class can be wrapped with decorators for weapons that boost attack power or armor that increases defense, enabling combinatorial builds without proliferating subclasses for each gear permutation. This approach is particularly effective in role-playing games (RPGs) and strategy titles, where it supports scalable ability systems and promotes code reuse across game assets.
Architecturally, the Decorator pattern underpins pluggable modules in microservices and plugin architectures by allowing core components to be extended with interchangeable behaviors at deployment or runtime. In microservices, decorators wrap repository or service interfaces to add persistence enhancements like caching or retry logic, ensuring separation of concerns and adaptability in evolving systems. This modularity aids in creating resilient, extensible architectures, as seen in .NET's infrastructure patterns for handling cross-cutting infrastructure needs.[17]
Integration with Other Patterns
The Decorator pattern often integrates with the Flyweight pattern to enable the addition of stateful or extrinsic behavior to shared, lightweight objects without compromising their memory efficiency. Flyweight objects store only intrinsic state that is common across instances, such as character glyphs in a document, while extrinsic state like position or formatting is managed externally. Decorators can wrap these flyweights at runtime to attach additional responsibilities, such as bolding or italicizing text, ensuring that the shared intrinsic data remains unbloated and reusable across multiple instances.[18][4]
A representative example occurs in text editors, where Flyweight objects represent shared character data (e.g., font metrics), and Decorator wrappers add instance-specific formatting like color or size without duplicating the underlying glyph structures. This combination maintains low memory footprint for large documents while allowing dynamic enhancements, as seen in glyph-based rendering systems.[19][4]
The Decorator pattern complements the Strategy pattern by enabling wrappers around interchangeable algorithms to compose behaviors dynamically at runtime. While Strategy defines a family of algorithms encapsulated in separate classes for selective use by a context, Decorator can extend individual strategy instances with cross-cutting concerns, such as logging, caching, or validation, without altering the core algorithm classes. For instance, a routing strategy in a navigation system could be decorated to include traffic-aware adjustments, allowing flexible stacking of enhancements atop the base strategy.[20][4]
Integration with the Adapter pattern allows Decorator to add new features while Adapter handles interface compatibility, or vice versa, creating hybrid wrappers for legacy or mismatched components. Adapter converts an incompatible interface to a client-expected one, whereas Decorator preserves the original interface but augments it; combining them permits adapting a decorated object to a new context, such as wrapping an enhanced legacy service to fit a modern API. This synergy is useful when extending third-party libraries with both adaptation and additional functionality dynamically.[21][4]
In the Observer pattern, Decorator can enhance subjects by adding or modifying notification behaviors without changing the core subject-observer dependency. A subject maintains a list of observers and notifies them of state changes; decorating the subject allows injection of specialized notification logic, such as event compression, multi-channel delivery (e.g., email and SMS), or conditional alerting, while preserving the one-to-many broadcast mechanism. For example, a news agency subject could be wrapped with a Decorator to support diverse subscriber types, dynamically extending notification capabilities.[22][23]
Challenges and Limitations
One significant challenge in applying the Decorator pattern arises from interfacing issues, where incomplete forwarding of methods in decorator classes can result in decorated objects failing to expose the full interface of the underlying component, potentially causing type mismatches or runtime errors when clients expect uniform behavior.[4] To mitigate this, developers should employ abstract decorator classes that enforce the complete interface implementation, ensuring transparency and compatibility across the chain.
Debugging complexity increases with the Decorator pattern due to deep chains of wrappers, which obscure call stacks and make it difficult to trace the origin of method invocations or errors, as the runtime behavior becomes distributed across multiple layers.[4] Limiting the depth of decorator chains through careful design and monitoring can help alleviate this issue, promoting maintainability without sacrificing flexibility.[24]
The pattern also introduces performance overhead from the extra indirection involved in method delegation through each decorator layer and the creation of numerous small objects for wrapping, which can accumulate in long chains and impact efficiency in resource-constrained environments.[25] Additionally, order dependency poses a limitation, as the final behavior of a decorated object varies based on the stacking sequence of decorators, necessitating meticulous management to achieve predictable outcomes.[4] Mitigation strategies include documenting stacking orders explicitly and using abstract base decorators to standardize interfaces, thereby reducing unintended interactions.[26]
Alternatives and Comparisons
The Decorator pattern, a structural design pattern for dynamically adding responsibilities to objects without subclassing, bears structural and conceptual similarities to other patterns but differs in intent and application.[9]
The Adapter pattern converts the interface of a class into another interface that clients expect, enabling collaboration between otherwise incompatible classes. Unlike Decorator, which wraps compatible objects to extend their behavior transparently, Adapter focuses on interface translation rather than enhancement, making it suitable for retrofitting existing components into new systems.[27][28]
The Composite pattern composes objects into tree structures to represent part-whole hierarchies, allowing clients to treat individual objects and compositions uniformly. While both patterns rely on recursive composition, Decorator emphasizes adding new responsibilities to a single object (such as embellishments), whereas Composite prioritizes uniform treatment of aggregates; the two are frequently combined, with Decorator applied to enhance leaf or composite nodes in a hierarchy.[29]
The Proxy pattern provides a placeholder for another object to control access, such as implementing lazy initialization, access protection, or remote invocation. It shares Decorator's structure of wrapping an object while preserving the same interface, but Proxy's primary goal is mediation and control rather than additive behavior extension.[28]
The Bridge pattern decouples an abstraction from its implementation so that the two can vary independently, often to avoid a large class hierarchy explosion. In contrast to Decorator's runtime, tightly coupled extensions via subclass-like wrappers, Bridge establishes this separation upfront through composition, supporting multiple abstraction-implementation pairings without direct inheritance.[30][28]
Designers should select the Decorator pattern for scenarios requiring flexible, transparent addition of behaviors to objects at runtime, preserving compatibility. Adapter suits interface mismatches, Composite hierarchical uniformity, Proxy controlled indirection, and Bridge independent evolution of abstractions and implementations.[31][4]
Inheritance vs. Composition Approaches
The Decorator pattern employs composition to extend object behavior dynamically, serving as a flexible alternative to inheritance-based subclassing for adding responsibilities. In contrast to inheritance, which defines extensions through static class hierarchies at compile time, the Decorator pattern uses wrapper objects to compose behaviors at runtime, allowing for greater adaptability without modifying existing code. This approach aligns with the principle of favoring composition over inheritance, as articulated in foundational object-oriented design literature.[4]
Inheritance introduces several drawbacks when used for behavioral extension, including the creation of rigid class hierarchies that can lead to an explosion of subclasses to accommodate varying combinations of features. Such hierarchies violate the open-closed principle (OCP), which states that software entities should be open for extension but closed for modification, as adding new behaviors often requires altering base classes or proliferating subclasses.[7] Furthermore, inheritance locks behavior into compile-time decisions, preventing runtime changes and limiting the ability to mix and match extensions across instances.[4]
The Decorator pattern's use of composition overcomes these limitations by enabling runtime stacking of behaviors through nested wrapper objects, each implementing the same interface as the core component. This facilitates easier testing of individual decorators in isolation and reduces coupling between extended functionalities, as components remain unaware of specific wrappers. By programming to an interface rather than concrete implementations, Decorator promotes loose coupling and adheres to the OCP without the fragility of deep inheritance chains.[7][4]
In terms of static versus dynamic extension, mixin inheritance represents a compile-time alternative, often implemented via multiple inheritance or templates (e.g., in C++), which weaves behaviors into classes during compilation for fixed combinations. Unlike mixins, which offer no runtime reconfiguration, the Decorator pattern provides dynamic flexibility, allowing behaviors to be added or removed based on context without recompilation. This makes mixins suitable for performance-critical, unchanging extensions, while Decorator excels in scenarios requiring variability.[32]
Preferences between the approaches depend on the extension's nature: inheritance or mixins are preferable for fixed, compile-time behaviors where performance and simplicity in a stable hierarchy are prioritized, whereas composition via Decorator is ideal for variable, runtime extensions that benefit from modularity. A key trade-off involves resource usage; deep inheritance hierarchies may consume less memory per instance due to shared code, but they can complicate maintenance, while Decorator's object proliferation through multiple wrappers increases memory footprint in highly stacked configurations, though it enhances flexibility.[4][7]
Implementation Examples
Java Implementations
The Decorator pattern in Java leverages the language's support for interfaces and inheritance to dynamically add behaviors to objects without modifying their underlying classes. A classic illustration is the graphical window system, where basic windows can be enhanced with features like borders or scrolling. This example, adapted from the original structural description, uses an interface for the core component and concrete decorators to wrap it, allowing transparent extension.[33]
Consider a Window interface defining a draw() method:
java
public interface Window {
void draw();
}
public interface Window {
void draw();
}
A concrete implementation, SimpleWindow, provides the basic drawing functionality:
java
public class SimpleWindow implements Window {
@Override
public void draw() {
System.out.println("Drawing a simple window");
}
}
public class SimpleWindow implements Window {
@Override
public void draw() {
System.out.println("Drawing a simple window");
}
}
An abstract WindowDecorator class holds a reference to a Window component and delegates calls to it:
java
public abstract class WindowDecorator implements Window {
protected Window window;
public WindowDecorator(Window window) {
this.window = window;
}
@Override
public void draw() {
window.draw();
}
}
public abstract class WindowDecorator implements Window {
protected Window window;
public WindowDecorator(Window window) {
this.window = window;
}
@Override
public void draw() {
window.draw();
}
}
Concrete decorators extend this abstract class to add specific behaviors. For instance, BorderDecorator adds a border:
java
public class BorderDecorator extends WindowDecorator {
public BorderDecorator(Window window) {
super(window);
}
@Override
public void draw() {
window.draw();
drawBorder();
}
private void drawBorder() {
System.out.println("Drawing a border around the window");
}
}
public class BorderDecorator extends WindowDecorator {
public BorderDecorator(Window window) {
super(window);
}
@Override
public void draw() {
window.draw();
drawBorder();
}
private void drawBorder() {
System.out.println("Drawing a border around the window");
}
}
Similarly, ScrollDecorator adds scrolling capability:
java
public class ScrollDecorator extends WindowDecorator {
public ScrollDecorator(Window window) {
super(window);
}
@Override
public void draw() {
window.draw();
drawScrollBars();
}
private void drawScrollBars() {
System.out.println("Drawing scroll bars on the window");
}
}
public class ScrollDecorator extends WindowDecorator {
public ScrollDecorator(Window window) {
super(window);
}
@Override
public void draw() {
window.draw();
drawScrollBars();
}
private void drawScrollBars() {
System.out.println("Drawing scroll bars on the window");
}
}
Usage involves chaining decorators, such as creating a bordered and scrollable window:
java
Window window = new ScrollDecorator(new BorderDecorator(new SimpleWindow()));
window.draw();
// Output:
// Drawing a simple window
// Drawing a border around the window
// Drawing scroll bars on the window
Window window = new ScrollDecorator(new BorderDecorator(new SimpleWindow()));
window.draw();
// Output:
// Drawing a simple window
// Drawing a border around the window
// Drawing scroll bars on the window
This chaining demonstrates how decorators compose behaviors additively while maintaining the Window interface, enabling polymorphic substitution in client code.[33]
Another common Java example is beverage customization, akin to a coffee shop system where base drinks are augmented with add-ons like milk or whipped cream. Here, a Beverage interface defines methods for description and cost:
java
public interface Beverage {
String getDescription();
double cost();
}
public interface Beverage {
String getDescription();
double cost();
}
A concrete Espresso class serves as the base component:
java
public class Espresso implements Beverage {
@Override
public String getDescription() {
return "Espresso";
}
@Override
public double cost() {
return 1.99;
}
}
public class Espresso implements Beverage {
@Override
public String getDescription() {
return "Espresso";
}
@Override
public double cost() {
return 1.99;
}
}
The abstract BeverageDecorator delegates to the wrapped beverage:
java
public abstract class BeverageDecorator implements Beverage {
protected Beverage beverage;
public BeverageDecorator(Beverage beverage) {
this.beverage = beverage;
}
@Override
public String getDescription() {
return beverage.getDescription();
}
@Override
public double cost() {
return beverage.cost();
}
}
public abstract class BeverageDecorator implements Beverage {
protected Beverage beverage;
public BeverageDecorator(Beverage beverage) {
this.beverage = beverage;
}
@Override
public String getDescription() {
return beverage.getDescription();
}
@Override
public double cost() {
return beverage.cost();
}
}
Concrete decorators, such as MilkDecorator, extend it to append details and costs:
java
public class MilkDecorator extends BeverageDecorator {
public MilkDecorator(Beverage beverage) {
super(beverage);
}
@Override
public String getDescription() {
return beverage.getDescription() + ", Milk";
}
@Override
public double cost() {
return beverage.cost() + 0.50;
}
}
public class MilkDecorator extends BeverageDecorator {
public MilkDecorator(Beverage beverage) {
super(beverage);
}
@Override
public String getDescription() {
return beverage.getDescription() + ", Milk";
}
@Override
public double cost() {
return beverage.cost() + 0.50;
}
}
A WhipDecorator adds similarly:
java
public class WhipDecorator extends BeverageDecorator {
public WhipDecorator(Beverage beverage) {
super(beverage);
}
@Override
public String getDescription() {
return beverage.getDescription() + ", Whip";
}
@Override
public double cost() {
return beverage.cost() + 0.75;
}
}
public class WhipDecorator extends BeverageDecorator {
public WhipDecorator(Beverage beverage) {
super(beverage);
}
@Override
public String getDescription() {
return beverage.getDescription() + ", Whip";
}
@Override
public double cost() {
return beverage.cost() + 0.75;
}
}
In practice, a customized espresso might be constructed as:
java
Beverage beverage = new WhipDecorator(new MilkDecorator(new Espresso()));
System.out.println(beverage.getDescription() + " $" + beverage.cost());
// Output: Espresso, Milk, Whip $3.24
Beverage beverage = new WhipDecorator(new MilkDecorator(new Espresso()));
System.out.println(beverage.getDescription() + " $" + beverage.cost());
// Output: Espresso, Milk, Whip $3.24
This setup allows flexible combinations without subclassing every possible variant, showcasing delegation and composition over inheritance.[34]
Java's standard I/O library exemplifies the Decorator pattern in production code, where classes like BufferedInputStream and DataInputStream wrap base InputStream implementations to add buffering or data parsing without altering the core interface. This design enables developers to layer stream functionalities dynamically, such as reading from a file with encoding conversion.[35]
Through these implementations, Java interfaces ensure that decorated objects remain interchangeable with originals, promoting the open-closed principle by allowing extension without modification.[33]
C++ Implementations
The dynamic implementation of the Decorator pattern in C++ relies on an abstract base class representing the core component, a concrete component implementing basic functionality, and decorator classes that wrap the component via a pointer, delegating calls while adding behavior. This approach allows runtime composition of objects, as outlined in the foundational design patterns literature.[36]
A typical structure uses an abstract Component class with a virtual method, such as operation(), which concrete classes override. The Decorator base class holds a pointer to a Component and forwards calls to it, while concrete decorators like ConcreteDecoratorA extend this by modifying the result before or after delegation. Memory allocation occurs dynamically with new, enabling chaining of decorators.
Here is a representative code example demonstrating this structure:
cpp
#include <iostream>
#include <memory>
#include <string>
// Abstract Component
class Component {
public:
virtual ~Component() = default;
virtual std::string operation() = 0;
};
// Concrete Component
class ConcreteComponent : public Component {
public:
std::string operation() override {
return "ConcreteComponent";
}
};
// Base Decorator
class Decorator : public Component {
protected:
std::shared_ptr<Component> component_; // Use shared_ptr for ownership management
public:
explicit Decorator(const std::shared_ptr<Component>& component) : component_(component) {}
std::string operation() override {
return component_->operation();
}
};
// Concrete Decorator A
class ConcreteDecoratorA : public Decorator {
public:
explicit ConcreteDecoratorA(const std::shared_ptr<Component>& component) : Decorator(component) {}
std::string operation() override {
return "ConcreteDecoratorA(" + Decorator::operation() + ")";
}
};
// Concrete Decorator B
class ConcreteDecoratorB : public Decorator {
public:
explicit ConcreteDecoratorB(const std::shared_ptr<Component>& component) : Decorator(component) {}
std::string operation() override {
return "ConcreteDecoratorB(" + Decorator::operation() + ")";
}
};
// Client usage
int main() {
auto simple = std::make_shared<ConcreteComponent>();
auto decorated = std::make_shared<ConcreteDecoratorA>(simple);
auto doubleDecorated = std::make_shared<ConcreteDecoratorB>(decorated);
std::cout << doubleDecorated->operation() << std::endl; // Output: ConcreteDecoratorB(ConcreteDecoratorA(ConcreteComponent))
return 0;
}
#include <iostream>
#include <memory>
#include <string>
// Abstract Component
class Component {
public:
virtual ~Component() = default;
virtual std::string operation() = 0;
};
// Concrete Component
class ConcreteComponent : public Component {
public:
std::string operation() override {
return "ConcreteComponent";
}
};
// Base Decorator
class Decorator : public Component {
protected:
std::shared_ptr<Component> component_; // Use shared_ptr for ownership management
public:
explicit Decorator(const std::shared_ptr<Component>& component) : component_(component) {}
std::string operation() override {
return component_->operation();
}
};
// Concrete Decorator A
class ConcreteDecoratorA : public Decorator {
public:
explicit ConcreteDecoratorA(const std::shared_ptr<Component>& component) : Decorator(component) {}
std::string operation() override {
return "ConcreteDecoratorA(" + Decorator::operation() + ")";
}
};
// Concrete Decorator B
class ConcreteDecoratorB : public Decorator {
public:
explicit ConcreteDecoratorB(const std::shared_ptr<Component>& component) : Decorator(component) {}
std::string operation() override {
return "ConcreteDecoratorB(" + Decorator::operation() + ")";
}
};
// Client usage
int main() {
auto simple = std::make_shared<ConcreteComponent>();
auto decorated = std::make_shared<ConcreteDecoratorA>(simple);
auto doubleDecorated = std::make_shared<ConcreteDecoratorB>(decorated);
std::cout << doubleDecorated->operation() << std::endl; // Output: ConcreteDecoratorB(ConcreteDecoratorA(ConcreteComponent))
return 0;
}
This example employs std::shared_ptr to manage ownership automatically via RAII, preventing memory leaks in chained decorators—a key C++ nuance since raw pointers require manual deletion.[36]
The static variant of the Decorator pattern in C++ leverages templates for compile-time composition, often implemented as a mixin where a decorator class inherits from a base template parameter, enabling zero-runtime-overhead extension without virtual functions. This approach, known as a template mixin or using the Curiously Recurring Template Pattern (CRTP) for polymorphism, allows flexible stacking of behaviors determined at compile time.
For instance, a base Shape class can be extended with a Colored mixin:
cpp
#include <iostream>
#include <string>
struct Shape {
virtual ~Shape() = default;
virtual std::string str() const = 0;
};
struct Circle : Shape {
float radius;
explicit Circle(const float radius) : radius(radius) {}
std::string str() const override {
return "A circle of radius " + std::to_string(radius);
}
};
template <typename Base>
class Colored : public Base {
std::string color;
public:
Colored(const std::string& color, Base* base) : Base(*base), color(color) {}
std::string str() const override {
return Base::str() + " has the color " + color;
}
};
int main() {
Circle circle(5.0f);
Colored<Circle> redCircle("red", &circle);
std::cout << redCircle.str() << std::endl; // Output: A circle of radius 5 has the color red
return 0;
}
#include <iostream>
#include <string>
struct Shape {
virtual ~Shape() = default;
virtual std::string str() const = 0;
};
struct Circle : Shape {
float radius;
explicit Circle(const float radius) : radius(radius) {}
std::string str() const override {
return "A circle of radius " + std::to_string(radius);
}
};
template <typename Base>
class Colored : public Base {
std::string color;
public:
Colored(const std::string& color, Base* base) : Base(*base), color(color) {}
std::string str() const override {
return Base::str() + " has the color " + color;
}
};
int main() {
Circle circle(5.0f);
Colored<Circle> redCircle("red", &circle);
std::cout << redCircle.str() << std::endl; // Output: A circle of radius 5 has the color red
return 0;
}
Such mixins expose the base's interface directly and support multiple inheritance for layering, contrasting with dynamic variants by avoiding indirection costs but requiring type knowledge upfront.
A practical application in C++ involves stream-like classes where decorators add features like buffering or encryption to a base Stream component. The base provides a read() method, while a BufferedStream decorator wraps it with an internal buffer for efficient I/O, and an EncryptedStream adds data transformation using a key. Chaining occurs via smart pointers to ensure RAII-compliant resource disposal, such as closing underlying files. This mirrors extensions in standard libraries like iostream for performance and security enhancements.
Illustrative code for a simplified stream example:
cpp
#include <iostream>
#include <memory>
#include <string>
#include <vector>
// Base Stream Component
class Stream {
public:
virtual ~Stream() = default;
virtual std::string read(int size) = 0;
};
// Concrete File Stream
class FileStream : public Stream {
public:
std::string read(int size) override {
// Simulate file read
return std::string(size, 'A'); // Dummy data
}
};
// Buffered Decorator
class BufferedStream : public Stream {
protected:
std::shared_ptr<Stream> stream_;
std::vector<char> buffer_;
size_t bufferPos = 0;
public:
explicit BufferedStream(const std::shared_ptr<Stream>& stream, size_t bufferSize = 1024)
: stream_(stream), buffer_(bufferSize), bufferPos(buffer_.size()) {}
std::string read(int size) override {
std::string result;
while (result.size() < size) {
if (bufferPos >= buffer_.size()) {
// Refill buffer
std::string chunk = stream_->read(buffer_.size());
buffer_.assign(chunk.begin(), chunk.end());
bufferPos = 0;
}
size_t toRead = std::min(size - result.size(), buffer_.size() - bufferPos);
result.append(buffer_.begin() + bufferPos, buffer_.begin() + bufferPos + toRead);
bufferPos += toRead;
}
return result;
}
};
// Encrypted Decorator (simple XOR for illustration)
class EncryptedStream : public Stream {
protected:
std::shared_ptr<Stream> stream_;
char key;
public:
explicit EncryptedStream(const std::shared_ptr<Stream>& stream, char encryptionKey)
: stream_(stream), key(encryptionKey) {}
std::string read(int size) override {
std::string data = stream_->read(size);
for (char& c : data) {
c ^= key; // Decrypt
}
return data;
}
};
// Client usage
int main() {
auto file = std::make_shared<FileStream>();
auto buffered = std::make_shared<BufferedStream>(file, 4);
auto encrypted = std::make_shared<EncryptedStream>(buffered, 42); // XOR key
std::cout << encrypted->read(5) << std::endl; // Outputs decrypted buffered data
return 0;
}
#include <iostream>
#include <memory>
#include <string>
#include <vector>
// Base Stream Component
class Stream {
public:
virtual ~Stream() = default;
virtual std::string read(int size) = 0;
};
// Concrete File Stream
class FileStream : public Stream {
public:
std::string read(int size) override {
// Simulate file read
return std::string(size, 'A'); // Dummy data
}
};
// Buffered Decorator
class BufferedStream : public Stream {
protected:
std::shared_ptr<Stream> stream_;
std::vector<char> buffer_;
size_t bufferPos = 0;
public:
explicit BufferedStream(const std::shared_ptr<Stream>& stream, size_t bufferSize = 1024)
: stream_(stream), buffer_(bufferSize), bufferPos(buffer_.size()) {}
std::string read(int size) override {
std::string result;
while (result.size() < size) {
if (bufferPos >= buffer_.size()) {
// Refill buffer
std::string chunk = stream_->read(buffer_.size());
buffer_.assign(chunk.begin(), chunk.end());
bufferPos = 0;
}
size_t toRead = std::min(size - result.size(), buffer_.size() - bufferPos);
result.append(buffer_.begin() + bufferPos, buffer_.begin() + bufferPos + toRead);
bufferPos += toRead;
}
return result;
}
};
// Encrypted Decorator (simple XOR for illustration)
class EncryptedStream : public Stream {
protected:
std::shared_ptr<Stream> stream_;
char key;
public:
explicit EncryptedStream(const std::shared_ptr<Stream>& stream, char encryptionKey)
: stream_(stream), key(encryptionKey) {}
std::string read(int size) override {
std::string data = stream_->read(size);
for (char& c : data) {
c ^= key; // Decrypt
}
return data;
}
};
// Client usage
int main() {
auto file = std::make_shared<FileStream>();
auto buffered = std::make_shared<BufferedStream>(file, 4);
auto encrypted = std::make_shared<EncryptedStream>(buffered, 42); // XOR key
std::cout << encrypted->read(5) << std::endl; // Outputs decrypted buffered data
return 0;
}
This chaining demonstrates pointer management with smart pointers to encapsulate lifetime, avoiding leaks in complex I/O hierarchies.
Python Implementation
In Python, the Decorator pattern is implemented through composition and inheritance, where concrete decorator classes wrap a base component object and extend its behavior without modifying the original classes. A classic example adapts the coffee shop scenario, featuring a base Beverage class with methods for calculating cost and retrieving a description, concrete beverage classes like Espresso, and decorator classes such as Milk and Whip that add their costs and descriptions while delegating to the wrapped component.[37]
The base Beverage class provides the common interface:
python
class Beverage:
def __init__(self):
self.description = "Unknown Beverage"
def cost(self):
return 0.0
def get_description(self):
return self.description
class Beverage:
def __init__(self):
self.description = "Unknown Beverage"
def cost(self):
return 0.0
def get_description(self):
return self.description
Concrete components implement specific beverages:
python
class Espresso(Beverage):
def __init__(self):
self.description = "Espresso"
def cost(self):
return 1.99
class HouseBlend(Beverage):
def __init__(self):
self.description = "House Blend Coffee"
def cost(self):
return 0.89
class Espresso(Beverage):
def __init__(self):
self.description = "Espresso"
def cost(self):
return 1.99
class HouseBlend(Beverage):
def __init__(self):
self.description = "House Blend Coffee"
def cost(self):
return 0.89
The abstract CondimentDecorator holds a reference to the wrapped beverage and delegates calls:
python
class CondimentDecorator(Beverage):
def __init__(self, beverage):
self.component = beverage
def get_description(self):
return self.component.get_description()
def cost(self):
return self.component.cost()
class CondimentDecorator(Beverage):
def __init__(self, beverage):
self.component = beverage
def get_description(self):
return self.component.get_description()
def cost(self):
return self.component.cost()
Concrete decorators extend this by adding their own costs and descriptions, using super() to invoke the parent's delegation:
python
class Milk(CondimentDecorator):
def __init__(self, beverage):
super().__init__(beverage)
def get_description(self):
return self.component.get_description() + ", Milk"
def cost(self):
return self.component.cost() + 0.10
class Whip(CondimentDecorator):
def __init__(self, beverage):
super().__init__(beverage)
def get_description(self):
return self.component.get_description() + ", Whip"
def cost(self):
return self.component.cost() + 0.45
class Milk(CondimentDecorator):
def __init__(self, beverage):
super().__init__(beverage)
def get_description(self):
return self.component.get_description() + ", Milk"
def cost(self):
return self.component.cost() + 0.10
class Whip(CondimentDecorator):
def __init__(self, beverage):
super().__init__(beverage)
def get_description(self):
return self.component.get_description() + ", Whip"
def cost(self):
return self.component.cost() + 0.45
This structure enables easy chaining of decorators, such as Whip(Milk(Espresso())), to build complex beverages dynamically. For instance, an espresso with milk and whip would have a description of "Espresso, Milk, Whip" and a total cost of 2.54.[37]
Python's dynamic typing and duck typing simplify the pattern by eliminating the need for explicit interfaces or abstract base classes, as compatibility is determined solely by the presence of required methods like cost() and get_description() rather than type declarations.[38] The use of super() facilitates clean delegation in the inheritance chain. Additionally, Python's support for multiple inheritance allows decorators to mix behaviors from various base classes if needed, though the core pattern relies on composition for stacking multiple wrappers without inheritance conflicts.[38]
Other Language Examples
In PHP, the Decorator pattern is typically implemented using an abstract Component class or interface that defines the core operation, such as rendering text, with concrete decorators extending it to add behaviors like uppercase conversion or trimming. For instance, an abstract RendererInterface might declare an render() method, implemented by a concrete TextRenderer that outputs plain text; decorators like UppercaseDecorator then wrap the component, calling the wrapped render() before applying transformations such as strtoupper(). This object-oriented approach leverages PHP's inheritance while allowing dynamic stacking of decorators for complex text processing pipelines.[39]
PHP's late static binding, introduced in version 5.3, enables decorators to reference the calling class in static contexts during inheritance chains, facilitating more flexible extensions in scenarios involving static factory methods or shared behaviors across decorator hierarchies.[40]
In Ruby, the Decorator pattern often employs dynamic class wrapping through composition, where a base Component module or class defines an operation method, and decorator classes hold a reference to the wrapped object, delegating calls while adding pre- or post-processing. An alternative static approach uses modules as mixins, included into classes to extend functionality without wrapping, such as mixing in logging or validation modules to a core component. Ruby's open classes further support this by allowing runtime extensions to existing classes, enabling seamless addition of decorator-like behaviors to third-party objects without subclassing. For example, a SimpleFormatter might be wrapped by BoldDecorator, which prepends and appends markup around the delegated output.[41]
The C# implementation mirrors Java's closely, relying on interfaces and abstract classes to define a Component with an Operation() method, where concrete decorators compose and extend behavior for tasks like stream processing—such as adding encryption or compression to a base Stream without altering its interface. A typical setup includes an IComponent interface, a ConcreteComponent implementation, an abstract Decorator class holding the component reference, and specialized decorators like ConcreteDecoratorA that modify the output, e.g., prefixing results from the wrapped operation. This enables runtime stacking for I/O streams, common in .NET for enhancing data flows dynamically.[42]
In Crystal, a statically typed language inspired by Ruby, the Decorator pattern utilizes structs for lightweight components and inheritance for type-safe wrapping, ensuring compile-time checks on decorator compatibility. The core structure involves an abstract base class or module defining operations, with concrete structs inheriting and composing via references to add behaviors, such as formatting time objects with locale-specific decorators while preserving the underlying type interface. This approach benefits from Crystal's union types and inference, preventing runtime errors in chained decorators.[43]