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.
There is no way to do that with standard Java permissions, but, luckily, OSGi introduces a solution.
These permissions are called implicit permissions, since every bundle will have them, whether the permissions are explicitly granted to the bundle or not.
The OSGi framework integrates their extended permissions model into the standard Java permissions model by subclassing 
Secure Cloud Development 
You must be logged in to post a comment.