The Decorator Pattern provides a mechanism to embellish the behaviour of an object without changing its essential interface. A decorated object should be able to be substituted wherever the original (non-decorated) object was expected. Decoration typically does not involve modifying the source code of the original object and decorators should be able to be combined in flexible ways to produce objects with several embellishments.
Suppose we have the following
There might be times when it is useful to timestamp a log message, or times when we might want to change the case of the message. We could try to build all of this functionality into our
Logger class. If we did that, the
Logger class would start to be very complex. Also, everyone would obtain all of features even when they might not want a small subset of the features. Finally, feature interaction would become quite difficult to control.
To overcome these drawbacks, we instead define two decorator classes. Uses of the
Logger class are free to embellish their base logger with zero or more decorator classes in whatever order they desire. The classes look like this:
We can use the decorators like so:
You can see that we embellish the logger behaviour with both decorators. Because of the order we chose to apply the decorators, our log message comes out capitalised and the timestamp is in normal case. If we swap the order around, let's see what happens:
Now the timestamp itself has also been changed to be uppercase.
A touch of dynamic behaviour
Our previous decorators were specific to
Logger objects. We can use Groovy's Meta-Object Programming capabilities to create a decorator which is far more general purpose in nature. Consider this class:
It takes any class and decorates it so that any
String method parameter will automatically be changed to lower case.
Just be careful with ordering here. The original decorators were restricted to decorating
Logger objects. This decorator work with any object type, so we can't swap the ordering around, i.e. this won't work:
We could overcome this limitation be generating an appropriate Proxy type at runtime but we won't complicate the example here.
Runtime behaviour embellishment
You can also consider using the
ExpandoMetaClass from Groovy 1.1 to dynamically embellish a class with behaviour. This isn't the normal style of usage of the decorator pattern (it certainly isn't nearly as flexible) but may help you to achieve similar results in some cases without creating a new class.
Here's what the code looks like:
This achieves a similar result to applying a single decorator but we have no way to easily apply and remove embellishments on the fly.
More dynamic decorating
Suppose we have a calculator class. (Actually any class would do.)
We might be interested in observing usage of the class over time. If it is buried deep within our codebase, it might be hard to determine when it is being called and with what parameters. Also, it might be hard to know if it is performing well. We can easily make a generic tracing decorator that prints out tracing information whenever any method on the
Calc class is called and also provide timing information about how long it took to execute. Here is the code for the tracing decorator:
Here is how to use the class in a script:
And here is what you would see after running this script:
Decorating with an Interceptor
The above timing example hooks into the lifecycle of Groovy objects (via
invokeMethod). This is such an important style performing meta-programming that Groovy has special support for this style of decorating using interceptors.
Groovy even comes with a built-in
TracingInterceptor. We can extend the built-in class like this:
Here is an example of using this new class:
And here is the output:
Decorating with java.lang.reflect.Proxy
If you are trying to decorate an object (i.e. just a particular instance of the class, not the class generally), then you can use Java's
java.lang.reflect.Proxy. Groovy makes working with this easier than just Java. Below is a code sample taken out of a grails project that wraps a
java.sql.Connection so that it's close method is a no-op:
If there were many methods to intercept, then this approach could be modified to look up closure in a map by method name and invoke it.
Decorating with Spring
The Spring Framework allows decorators to be applied with interceptors (you may have heard the terms advice or aspect). You can leverage this mechanism from Groovy as well.
First define a class that you want to decorate (we'll also use an interface as is normal Spring practice):
Here's the interface:
Here's the class:
Now, we define our wiring in a file called
beans.xml as follows:
Now, our script looks like this:
And when we run it, we see the results:
You may have to adjust your
logging.properties file for messages at log level
FINEST to be displayed.
Asynchronous Decorators using GPars
Using the example code in Panini for inspiration. Here is a Groovy version that avoids using an
@AddedBehavior annotation at the expense of not having as general an algorithm for selecting the methods to decorate. This isn't a limitation of the particular approach chosen but just a simplification for illustrative purposes (but don't assume below is an exact equivalent).