Also known as: Wrapper


We're working on a substantial update for the whole design patterns section that should be ready by the end of September. Until then, please sorry for all embarrassing typos and errors you might encounter here and there.

The progress can be tracked via email or on Facebook.


Decorator is a structural design pattern that lets you attach new behaviors to objects by placing them inside wrapper objects that contain these behaviors.


You have to add and remove responsibilities from an object dynamically, but do it in a way so that it stay compatible with the rest of application's code.

Inheritance is the first solution that comes to mind when you need to extend class behaviors. However, the inheritance is static. You can not add new subclasses to a program when it is already compiled and executed.


The decorator pattern relies on special objects called decorators (or wrappers). They have the same interface as an object that they suppose to wrap, so the client code will not notice when you hand it a wrapper instead of the original object.

All wrappers have a field for storing an instance of an original object. Most wrappers initialize that field with an object passed into their constructor.

So how do they dynamically change the behavior? As I mentioned, wrappers have the same interface as the target objects. When you call a decorator's method, it executes the same method in a wrapped object and then adds something to the result. It can also be called before the original method, but that is up to the business logic.

Here is the interesting part: you can wrap an object with a decorator, and then wrap the result with another decorator, and so on. The resulting behavior will be a combination of all decorators and the original object.

Real-World Analogy


Wearing clothes is an example of using decorators. When you are cold, you wrap yourself with a sweater. If it is still cold, you can wear a jacket on top. If it is raining, you can put on a raincoat.

All of these garments "extend" your basic behavior, but are not part of you. Therefore you can easily take them off whenever you do not need them anymore.


Decorator design patternDecorator design pattern
  1. Component declares the common interface for both wrappers and wrapped objects.

  2. Concrete Component is a class that contains basic behavior that can be altered by decorators.

  3. Base Decorator contains a field for storing wrapped objects. The field should be declared with a Component type to support both Concrete Components and Decorators. Base decorator delegates all operations to a wrapped object.

  4. Concrete Decorators contain extra behaviors that can be dynamically added to the components. Decorators may execute their behavior either before or after calling the same method in wrapped object.


In this example, Decorator helps to protect financial data with encryption implicitly to the existing code. Application wraps the financial object with an encryption and compression decorators, that return plain data when reading from disk, but encrypt and compress data when writing it back.

Both decorators and the financial class have a common interface that makes them interchangeable for a client code.

// The common interface for all components.
interface DataSource is
    method writeData(data)
    method readData():data

// The concrete component act as a base layer.
class FileDataSource implements DataSource is
    constructor FileDataSource(filename) { ... }

    method writeData(data) is
        // Write data to file.

    method readData():data is
        // Read data from file.

// The base decorator contains wrapping behavior.
class DataSourceDecorator implements DataSource is
    protected field wrappee: DataSource

    constructor DataSourceDecorator(source: DataSource) is
        wrappee = source

    method writeData(data) is

    method readData():data is
        return wrappee.readData()

// Concrete decorators add to a result they get from a component
// they wrap.
class EncyptionDecorator extends DataSourceDecorator is
    method writeData(data) is
        // 1. Encrypt passed data.
        // 2. Pass encrypted data to wrappee's writeData method.

    method readData():data is
        // 1. Get data from wrappee's readData method.
        // 2. Try to decrypt it if it's encrypted.
        // 3. Return the result.

// You can wrap objects in several layers of decorators.
class CompressionDecorator extends DataSourceDecorator is
    method writeData(data) is
        // 1. Compress passed data.
        // 2. Pass compressed data to wrappee's writeData
        // method.

    method readData():data is
        // 1. Get data from wrappee's readData method.
        // 2. Try to decompress it if it's compressed.
        // 3. Return the result.

// Option 1. A simple example of decorator assembly.
class Application is
    method dumbUsageExample() is
        source = new FileDataSource("somefile.dat")
        // The target file has been written with plain data.

        source = new CompressionDecorator(source)
        // The file has been written with compressed data.

        source = new EncyptionDecorator(source)
        // The source variable is now containing this:
        // Encryption > Compression > FileDataSource
        // The file has been written with compressed and
        // encrypted data.

// Option 2. The client code that uses an external data source.
// SalaryManager objects neither know nor care about data
// storage specifics. They work with pre-configured data source,
// received from the app configurator.
class SalaryManager is
    field source: DataSource

    constructor SalaryManager(source: DataSource) { ... }

    method load() is
        return source.readData()

    method save() is
    // ...Other useful methods...

// The app is able to assemble different stacks of decorators at
// run time, depending on the configuration or environment.
class ApplicationConfigurator is
    method configurationExample() is
        source = new FileDataSource("salary.dat")
        if (enabledEncryption)
            source = new EncyptionDecorator(source)
        if (enabledCompression)
            source = new CompressionDecorator(source)

        logger = new SalaryManager(source)
        salary = logger.load()
    // ...


When you need to dynamically assign the behaviors to objects without breaking the code that uses these objects.

The Decorator pattern allows assigning new behaviors to objects dynamically and implicitly to a client code. Objects can be wrapped with multiple wrappers at the same time, resulting in a stacking behavior of all wrappers.

When it is not possible or awkward to extend the object behavior with inheritance.

Many programming languages have the final keyword that can be used to prevent further extension of a class. When dealing with such code, the only option for the extension is to use the Decorator pattern.

How to Implement

  1. Make sure that your task can be represented as one primary component and several optional extensions over it.

  2. Create the Component interface that should describe all common methods for that primary component ant its extensions.

  3. Create the Concrete Component class and put the primary business logic in it.

  4. Create the Base Decorator class. Create a field for storing wrapped objects. It should have a Component interface type to allow storing both components and decorators inside.

  5. Make sure that all classes implement the Component interface.

  6. Make all the methods of the Base Decorator delegating execution to the methods of the wrapped object. It will allow Concrete Decorators to extend only a portion of the component's behavior and leave the rest intact.

  7. Create Concrete Decorator classes by extending them from the Base Decorator.

  8. A Concrete Decorator should execute its behavior prior or after the call to the same method in a wrapped object (you can just call a parent's method since it will end up calling the wrapped method).

  9. Client code must be responsible for configuring layers of wrapping. Client should work with all classes through a Component's interface to make the decorators interchangeable.

Pros and Cons

  • Much more flexible than class inheritance.
  • Allows adding and removing behaviors at runtime.
  • Allows combining several additional behaviors by using multiple wrappers.
  • Allows composing complex objects from simple ones instead of having monolithic classes that implement every variant of behavior.
  • It is hard to configure a multi-wrapped object.
  • Lots of small classes.

Relations with Other Patterns

  • Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface.

  • Adapter is meant to change the interface of an existing object. Decorator enhances another object without changing its interface. Decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports recursive composition, which isn't possible with pure Adapters.

  • Chain of Responsibility and Decorator have very common class structures. They both rely on the recursive composition to pass execution through a series of objects. But there are also several crucial differences.

    The Chain of Responsibility handlers can execute arbitrary actions, independent of each other. They can also terminate further chaining of the request at will. On the other hand, various Decorators extend a particular behavior and suppose to keep its interface consistent. Also, Decorators are not allowed to break the execution chain at will.

  • Composite and Decorator have similar structure diagrams since they both rely on recursive composition to organize an open-ended number of objects.

    Decorator can be viewed as a degenerate Composite with only one component. However, Decorator adds additional responsibilities to the object while Composite just "summs up" of the same behavior executed over its children.

    But they can also cooperate: Composite can use Decorator to change behavior of the tree components.

  • Designs that make heavy use of the Composite and Decorator patterns often can benefit from Prototype as well. It would allow to clone complex structures, instead of re-constructing them from scratch.

  • Decorator lets you change the skin of an object. Strategy lets you change the guts.

  • Decorator and Proxy have similar structures but different purposes. Both patterns built on the composition principle of delegating work to other object. However, the Proxy manages the life cycle of its service object by itself, whereas Decorator structure is controlled by client.

Implementations in Different Programming Languages

Decorator Java Decorator C# Decorator PHP