I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Design Patterns Uncovered: The Decorator Pattern

03.15.2010
| 43780 views |
  • submit to reddit

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. The definition of Decorator provided in the original Gang of Four book on Design Patterns 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 component
public 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 decorator
public 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 decorator
public 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.

 

Other Articles in This Series
The Observer Pattern
The Adapter Pattern
The Facade Pattern
The Factory Method Pattern
The Abstract Factory Pattern
The Singleton Pattern
The Strategy Pattern

Next Up

 The next pattern will be the Chain of Responsibility.

Tags:

Comments

Tracy Nelson replied on Mon, 2010/03/15 - 11:06am

I would mention that dynamic proxies are often a good choice when implementing Decorators.  By deferring non-extended operations to the proxied class, you can isolate your code (somewhat) from changes to the decorated class.  That is, if a new method is added to the interface, you don't have to add a corresonding stub to your decorator.

Javin Paul replied on Sat, 2011/11/19 - 12:49am

Thanks for clear explanation. What is most important point with decorator is that it affect only individual object and not all object which itself a big control and flexibility inheritance doesn't offer. See here for another example of decorator pattern in Java

nilesh gule replied on Wed, 2012/07/04 - 11:07am

Nice post. I recently posted about Decorator design pattern in C# using Order Manager as an  example. Because of the similarities between C# and Java it might be helpful for reader to get a look at another implementation of Decorator Design Pattern.

http://www.nileshgule.com/2012/07/decorator-design-pattern.html

Except for the minor differences in keywords, I think most of the code in C# can be ported over to java as is. Hope this helps. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.