|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Programming with plain-old Java objects (POJOs) is rather popular these days. When we program with POJOs, we can apply object-oriented programming (OOP) pretty easily. But sometimes implementing cross-cutting aspects throughout an application using OOP proves difficult. For example, generally implementing logging or security in our POJO business objects throughout an application is difficult to achieve with OOP. Dynamic proxies, which were introduced in J2SE 1.3, offer an easier solution.
The idea behind dynamic proxies is to include dynamic behavior around an object, yet neither change the object's existing code nor its interface. The famous Gang of Four (GoF) Decorator pattern provides a way to decorate an object (change its behavior) without changing the object code and allows us to add cross-cutting aspects to our business objects. Many existing frameworks and tools use this pattern. But when implementing static decorating, the pattern imposes some problems, which I discuss later in the article.
Prior to the introduction of dynamic proxies, there was no direct way to decorate objects dynamically. So vendors came up with tools to generate code automatically and decorate objects. Though a code-generation tool can help us generate static decorators, it requires extra steps and also introduces overhead for maintaining the generated code. By using dynamic proxies, we can greatly reduce this auto-generated code (perhaps to zero).
To see how dynamic proxies work, let's take an example of the classic Decorator pattern as a method interceptor and see what dynamic proxies can offer in its place. If we use dynamic proxies as is, we may face some coding complexities. Later in the article, you will see how to wrap these complexities involved with dynamic proxies and provide an abstraction over them. Most of the source code used in this article can be downloaded from Resources.
Suppose we have a simple business interface:
public interface IMyBusinessObject {
public String doExecute(String in);
}
And this implementation of a business object class:
public class MyBusinessObject implements IMyBusinessObject {
public String doExecute(String in) {
System.out.println("Here in MyBusinessObject doExecute: input :" + in);
return in;
}
}
Now we want to add some behavior (e.g., logging) before and after the doExecute() method. The Decorator pattern helps us easily add this functionality.
We define an abstract decorator class like the following:
public abstract class ADecorator implements IMyBusinessObject {
protected IMyBusinessObject target;
public void setTarget(IMyBusinessObject target_) {
this.target = target_;
}
public ADecorator(){}
public ADecorator(IMyBusinessObject target_) {
setTarget(target_);
}
}
Now we define a concrete DebugConcreteDecorator, which extends ADecorator. Our intention is to add debug messages before and after our business object's method invocation:
public class DebugConcreteDecorator extends ADecorator {
public String doExecute(String in) {
System.out.println("DebugConcreteDecorator: before method : doExecute ");
String ret = target.doExecute(in);
System.out.println("DebugConcreteDecorator: after method : doExecute ");
return ret;
}
}
Now from the client code, we call our business object:
Archived Discussions (Read only)