Sunday, May 14, 2006

NFJS - Spring AOP

Presented by Stuart Halloway, Relevance, LLC

This seminar provided a deeper dive in to AOP with Spring. As mentioned earlier, Spring uses Dependency Injection and the IOC pattern to minimize dependencies. But sometimes, there are dependencies that are too broad to be removed using DI. In many of these instances, AOP can solve the problem. The simple (yet powerful) example Stuart provided was that of three inheritance trees:

SuperBeing SoftwareProject
^ ^ ^
| | |
| -------- |
| | |
SuperHero SuperVillain OpenSourceProject Server

 


Assume that each of the classes has an attribute name and we need to validate the name when it is set. Placing a name validation method in each of the four concrete classes would result in repeating the code four times. But since we understand OO concepts, we move the method into the base classes to reduce repetition. Now we only have to repeat the code three times!?! Not a great improvement. But with AOP (in Spring), we write the name validation method one time and using a Spring configuration file, attach the method to every class that needs it. This, in a nutshell, is what AOP is all about. Note that this mechanism is so powerful, we could add the name validation method to a class even if we don’t have the source code for it.

The name validation requirement in the previous example is referred to in AOP as a “cross cutting concern”. In non-AOP systems, cross cutting concerns often result in a lot of code duplication. When this code is isolated in one place with AOP, it is referred to as “advice”. The point where advice is applied in the code is called a “joinpoint”. A collection of all joinpoints for a given piece of advice is called a “pointcut”. The combination of a pointcut with its advice is called an “aspect”. Lots of new terminology, but it didn’t take long for it to make sense.

Stuart presented several examples that illustrated how aspects could be applied to a class, including method intercept, before method, after method, and throw only. The Spring framework implements AOP natively and is relatively easy to use. For higher efficiency implementations, Spring also supports AspectJ. It was mentioned that it is straightforward to start with Spring AOP and migrate to AspectJ.

It should be pointed out that the primary mechanism for implementing aspects is to modify the byte code of the class being aspected. It was interesting that Stuart offered the same advice on concerns about this that Dr. Venkat Subramaniam did at a JUG meeting a couple of months ago, which was, “Get over it!” Stuart followed this with an observation that wound up being a “Got it!” moment for me. He compared people who complain that they can’t directly see aspects in the code and therefore worry about what is being executed to similar criticisms in the past about OO and how you couldn’t see what code was being executed because of inheritance hierarchies. Not only do I remember these criticisms, I was guilty of making them early on (he admitted shamefully). So I am happy to say that I have “gotten over it” and am really looking forward to investigating AOP. I’ll probably start with the Spring version, but hope to try AspectJ soon as well.

No comments: