One 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.
Last time, I wrote about 
If your organization doesn’t have something like our PSO, you can look elsewhere. (And if it does, you should look outside too!)
You may think you know very little yet, but even then it’s valuable to share.
I work at 
The 
For authentication in an HTTP world, it makes sense to look at 
If you’re in the HTTP API building and/or consuming business –and who isn’t these days– then please go ahead and read the draft and 
Java on the client has failed to reached widespread adoption, and now that many people advice to 
JavaScript on the server is starting to make inroads, thanks to the 
Last week, I spend several days fixing a bug that only surfaced in a distributed environment.
So how would a Frictionless Development Environment do version control for us?
The basic point is that we can formally define a pipeline of processes that we want to run automatically.
One of the important things in a 
The process outlined above works well for making our software ever more secure.
Some people object to the Zero Defects mentality, claiming that it’s unrealistic.
Mobile code in source form requires an interpreter to execute, like 
Examples of active content are HTML pages or 
A simple bug that causes the mobile code to go into an infinite loop will threaten your application’s 
One of those approaches is to verify that the mobile code is made by a trusted source and that it has not been tampered with.
After restricting what mobile code may run at all, we should take the next step: prevent the running code from doing harm by restricting what it can do.
Ray on Software Architecture 
You must be logged in to post a comment.