Home » Java » Core Java » The Decorator Pattern

About Remon Sinnema

The Decorator Pattern

The Decorator Pattern

decoratingOne design pattern that I don’t see being used very often is Decorator. I’m not sure why this pattern isn’t more popular, as it’s quite handy. The Decorator pattern allows one to add functionality to an object in a controlled manner. This works at runtime, even with statically typed languages! The decorator pattern is an alternative to subclassing. Subclassing adds behavior at compile time, and the change affects all instances of the original class; decorating can provide new behavior at run-time for individual objects. The Decorator pattern is a good tool for adhering to the open/closed principle.

Some examples may show the value of this pattern:

Example 1: HTTP Authentication

Imagine an HTTP client, for example one that talks to a RESTful service.

Some parts of the service are publicly accessible, but some require the user to log in. The RESTful service responds with a 401 Unauthorized status code when the client tries to access a protected resource.

Changing the client to handle the 401 leads to duplication, since every call could potentially require authentication. So we should extract the authentication code into one place. Where would that place be, though?

Here’s where the Decorator pattern comes in:

public class AuthenticatingHttpClient
    implements HttpClient {

  private final HttpClient wrapped;

  public AuthenticatingHttpClient(HttpClient wrapped) {
    this.wrapped = wrapped;
  }

  @Override
  public Response execute(Request request) {
    Response response = wrapped.execute(request);
    if (response.getStatusCode() == 401) {
      authenticate();
      response = wrapped.execute(request);
    }
    return response;
  }

  protected void authenticate() {
    // ...
  }

}

A REST client now never has to worry about authentication, since the AuthenticatingHttpClient handles that.

Example 2: Caching Authorization Decisions

OK, so the user has logged in, and the REST server knows her identity. It may decide to allow access to a certain resource to one person, but not to another.

IOW, it may implement authorization, perhaps using XACML. In that case, a Policy Decision Point (PDP) is responsible for deciding on access requests.

Checking permissions it often expensive, especially when the permissions become more fine-grained and the access policies more complex. Since access policies usually don’t change very often, this is a perfect candidate for caching.

This is another instance where the Decorator pattern may come in handy:

public class CachingPdp implements Pdp {

  private final Pdp wrapped;

  public CachingPdp(Pdp wrapped) {
    this.wrapped = wrapped;
  }

  @Override
  public ResponseContext decide(
      RequestContext request) {
    ResponseContext response = getCached(request);
    if (response == null) {
      response = wrapped.decide(request);
      cache(request, response);
    }
    return response;
  }

  protected ResponseContext getCached(
      RequestContext request) {
    // ...
  }

  protected void cache(RequestContext request, 
      ResponseContext response) {
    // ...
  }

}

As you can see, the code is very similar to the first example, which is why we call this a pattern.

As you may have guessed from these two examples, the Decorator pattern is really useful for implementing cross-cutting concerns, like the security features of authentication, authorization, and auditing, but that’s certainly not the only place where it shines.

If you look carefully, I’m sure you’ll be able to spot many more opportunities for putting this pattern to work.
 

Reference: The Decorator Pattern from our JCG partner Remon Sinnema at the Secure Software Development blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

 

5 comments

  1. Hello Remon, I like this pattern and you explain it very well, I have only 1 complain: I think class names should be pronouns like –> HTTPClientAuthenticator and PDPCacheResolver (?) or PDPCacher (?) or PDPCacheWorker even PDPCacheDecorator so the people who has knowledge about the pattern will notice it instantly :).

    • Hi Joseph,

      Thanks for reading an commenting.

      I’m no linguist, but it seems to me that CachingPdp consists of an adjective and a noun. I agree that there should be a noun in there (not a pronoun). An adjective “serves as a modifier of a noun to denote a quality of the thing named, to indicate its quantity or extent, or to specify a thing as distinct from something else ” (http://www.merriam-webster.com/dictionary/adjective), which seems highly appropriate to me.

      I don’t like PDPCacheDecorator, since it’s a technical name that focuses on the how rather than the what.

      • Remon, my bad about pronouns (that was a blackout) Yes, I mean nouns. You are right about PDPCacheDecorator that’s why I say “even”, it’s of course the last resort (I wouldn’t use it personally) but what I’m trying to point here is CachingPDP sounds (to me) more like a method than a class, PDPCacheResolver would be a class name I expect for a class that issue the process of PDP cache.

  2. Hello Remon, the decorator pattern is used a lot with streams: for example, Java I/O classes

    • Yes. This allows you to do something like:
      new BufferedReader(new InputStreamReader(new FileInputStream(new File(path))))
      where you keep adding functionality by decorating objects. This keeps the individual decorator classes small and focused, reducing the chance of bugs.

Leave a Reply

Your email address will not be published. Required fields are marked *

*


Want to take your Java Skills to the next level?
Grab our programming books for FREE!
  • Save time by leveraging our field-tested solutions to common problems.
  • The books cover a wide range of topics, from JPA and JUnit, to JMeter and Android.
  • Each book comes as a standalone guide (with source code provided), so that you use it as reference.
Last Step ...

Where should we send the free eBooks?

Good Work!
To download the books, please verify your email address by following the instructions found on the email we just sent you.