Decorator Pattern Tutorial with Java Examples

Today's pattern is the Decorator pattern, which allows class behaviour to be extended dynamically at runtime.

Decorator in the Real World

The concept of a decorator is that it adds additional attributes to an object dynamically. A real world example of this would be a picture frame. The picture is our object, which has it's own characteristics. For display purposes we add a frame to the picture, in order to decorate it. You're probably already familiar with the concept of wrapper objects, and in essence, that is what a Decorator is.  

Design Patterns Refcard
For a great overview of the most popular design patterns, DZone's Design Patterns Refcard is the best place to start.

The Decorator Pattern

The Decorator is known as a structural pattern,as it's used to form large object structures across many disparate objects. Thedefinition of Decorator provided in the original Gang of Four book on DesignPatterns states:

Allows for the dynamic wrapping of objects in order to modify their existing responsibilities and behaviours 

Traditionally, you might consider subclassing to be the best way to approach this - but there will be cases that subclassing isn't possible, or is impractical. This leads us to the Open/Closed Principle: classes should be open for extension, but closed for modification. This is a good principle to keep in mind, as it keeps your class stable, but leaves it open for extension if someone wants to add behaviour. 

Let's take a look at the diagram definition before we go into more detail.

The Component defines the interface for objects that can have responsibilties added dynamically, and the ConcreteComponent is simply an implementation of this interface. The Decorator has a reference to a Component, and also conforms to the  Component interface.  This is the important thing to remember, as the Decorator is essentially wrapping the Component. The ConcreteDecorator just adds responsibilities to the original Component. 

Would I Use This Pattern?

The Decorator pattern should be used when:

• Object responsibilities and behaviours should be dynamically modifiable
• Concrete implementations should be decoupled from responsibilities and behaviours

As mentioned in the previous section, this can be done by subclassing. But too much subclassing is definitely a bad thing. As you add more behaviours to a base class, you will soon find yourself dealing with maintenance nightmare, as a new class is created for each possible combination. While the decorator can cause it's own issues, it does provide a better alternative to too much subclassing.

So How Does It Work In Java?

You'll see decorators being used in Java I/O streams. Stream classes extend the base subclasses to add features to the stream classes.

In our example, we'll use emails to illustrate the Decorator. 

First we have an email interface, which has a getContents method: 

public interface IEmail{   public String getContents();   }

And we'll provide a concrete implementation for use: 

//concrete componentpublic class Email implements IEmail{   private String content;      public Email(String content)   {      this.content = content;   }   @Override   public String getContents()   {      //general email stuff      return content;   }}

Now we'll create a decorator which will wrap the base email with extra functionality. We'll model this as an abstract class, and maintain a reference to the base email.

public abstract class EmailDecorator implements IEmail{   //wrapped component   IEmail originalEmail;      }

Let's say that emails that leave the company internal server need to have a disclaimer added to the end. We can just add in a decorator to handle this: 

//concrete decoratorpublic class ExternalEmailDecorator extends EmailDecorator{   private String content;       public ExternalEmailDecorator(IEmail basicEmail)   {      originalEmail = basicEmail;   }      @Override   public String getContents()   {            //  secure original       content = addDisclaimer(originalEmail.getContents());      return content;   }         private String addDisclaimer(String message)   {      //append company disclaimer to message      return  message + "\n Company Disclaimer";   }   }

And if we wanted to create secure, encrypted messages, we could use another decorator: 

//concrete decoratorpublic class SecureEmailDecorator extends EmailDecorator{   private String content;       public SecureEmailDecorator(IEmail basicEmail)   {      originalEmail = basicEmail;   }      @Override   public String getContents()   {            //  secure original       content = encrypt(originalEmail.getContents());      return content;   }         private String encrypt(String message)   {      //encrypt the string       return  encryptedMessage;   }   }

So, if our email sending client detects this message is going outside the company, we can invoke the appropriate decorator before sending: 

public class EmailSender{      public void sendEmail(IEmail email)   {      //read the email to-address, to see if it's going outside of the company      //if so decorate it       ExternalEmailDecorator external = new ExternalEmailDecorator(email);      external.getContents();      //send          }}

Watch Out for the Downsides

Overuse of the Open/Closed principle can lead to abstract and complex code. This principle should really only be used in places where code is least likely to change.

The Design Patterns book does point out a couple of disadvantages with this pattern. Decorators can lead to a system with a lot of smaller objects that will look similar to a developer and introduce a maintenance headache. Also, the Decorator and it's enclosed components are not identical, so tests for object type (instanceof) will fail.

Next Up

 The next pattern will be the Chain of Responsibility.

Enjoy the Whole "Design Patterns Uncovered" Series:

Creational Patterns

• Learn The Abstract Factory Pattern
• Learn The Builder Pattern
• Learn The Factory Method Pattern
• Learn The Prototype Pattern

Structural Patterns

• Learn The Adapter Pattern
• Learn The Bridge Pattern
• Learn The Decorator Pattern
• Learn The Facade Pattern
• Learn The Proxy Pattern

Behavioral Patterns

• Learn The Chain of Responsibility Pattern
• Learn The Command Pattern
• Learn The Interpreter Pattern
• Learn The Iterator Pattern
• Learn The Mediator Pattern
• Learn The Memento Pattern
• Learn The Observer Pattern
• Learn The State Pattern
• Learn The Strategy Pattern
• Learn The Template Method Pattern
• Learn The Visitor Pattern