Implementing the Decorator Pattern in AspectJ

Last week we covered how we'd implement the decorator pattern in Java to solve how to modify the behavior of an existing class without modifying or subclassing it. It turns out that implementing this behavior is even simpler in AspectJ.For a refresher on the decorator pattern, read the preceding post.

As before, say we have a Car class which has some functionality we'd like to modify, say by adding a top to the car or an engine. Listing 1 shows a Car interface and SimpleCar class.

Listing 1: Car Interface and SimpleCar Class

To add a top or an engine, we'd need separate classes for each functionality, and an abstract class that they extend. But instead, we can just add two aspects (see Listing 2).

Listing 2: TopAspect and EngineAspect Aspects

Each aspect modifies the code so that it performs some behavior prior to calling drive(), and it modifies the getInfo method. Both aspects total twelve lines of code (not including braces), whereas the equivalent code in Java totals nearly double the lines at twenty-two.

We can view the results of the Decorator pattern by calling the getInfo method, which should return "car, with top, with revved engine".

Listing 3: DecoratedTest Class

Line three is very straightforward, whereas the equivalent line in the Java-only implementation is a bit more convoluted, as each constructor must be called for each class. For multiple classes, it can be quite unwieldy.

This is a bit perfect example of using AspectJ's interception capabilities to add a crosscutting concern. In a more realistic example, Car could be a communication class, and TopAspect could be a logger, while EngineAspect could be an encryption engine. In this way, Car could be written without "concern" for logic unrelated to itself, and these new aspects could be added later.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu

Implementing the Decorator Pattern in Java

At the Institute for Cyber Security, our software architects help fulfill the role of CTOs for new security startups, and will work with development teams to come up with technical solutions to existing development problems. In one recent example, one developer had to modify the behavior of an existing code base but could not modify the code due to licensing.

Normally, the solution is to subclass the original class, then add your behavior as necessary. However, in this case, the class was finalized, meaning the class could not be inherited. This stumped our intrepid developer--surely someone must have solved this problem before!

In software engineering, a design pattern is a general reusable solution to a commonly occurring software design problem. As you may have surmised from the title of this post, our architect recognized the issue and recommended the decorator pattern. This allows new behavior to be added to an existing class dynamically (assuming some design work had been done in advance) as an alternative to subclassing.

The decorator pattern is achieved by designing a new decorator class that wraps the original class. This wrapping could be achieved by the following sequence of steps:

1. Create an interface and the base "component" class that implement it.
2. Implement the interface into a "decorator" class.
3. In the Decorator class, add a Component "pointer" as a field;
4. Pass a Component to the Decorator constructor to initialize the Decorator's Component;
5. In the Decorator class, redirect all "Component" methods to the internal Component pointer and override any Component method(s) whose behavior needs to be modified.

This pattern is designed so that multiple decorators can be "stacked" on top of each other, each time adding a new functionality to the overridden method(s).

The above listing is best demonstrated by example.Consider the following: we have a Car class which has some functionality we'd like to modify, say by adding a top to the car or an engine. Listing 1 shows a Car interface and SimpleCar class.

Listing 1: Car Interface and SimpleCar Class

To add a top or an engine, we'd need separate classes for each functionality, and an abstract class that they extend (see Listing 2):

Listing 2: CarDecorator, TopDecorator, and EngineDecorator Classes

Using Listing 3, we can view the results of the Decorator pattern by calling the GetInfo method, which should return "car, with top, with revved engine".

Listing 3: DecoratedTest Class

In some dynamic languages, this can be more easily achieved, but in Java, this seals the deal and our developer was able to walk away, not only with a solution to his specific problem, but with a broader understanding of design patterns in general.

Erhan J. Kartaltepe,
erhan.kartaltepe-at-utsa.edu