Learning about AOP

I was told that once I start writing code in AspectJ and learn in depth Aspect Oriented Programming (AOP), it will be difficult to look at Java source code again in the same way as before. And now, the more I get into it, the more I realize how important it is to have this knowledge as part of your skill set. Until now, I had heard a lot about AOP and, just as anyone else who has used the Spring Framework, I thought I knew all I would ever need from AOP. Then, I was presented with a challenge where Spring support was not enough so I was faced with the opportunity to learn AspectJ's language constructs to address my client's concerns. I was very impressed with the things I was able to accomplish with this extension to the language and in general I highly recommend everyone to take the time to learn it and use it often.

One of biggest goals and hopes of every Software Architect is to design and lead a software development effort that can scale well. This means that maintenance should be more than technically feasible, but rather simple enough within budget. Experience proves that despite every effort of preparing for every change, it is difficult to address every potential concern that will rise in the future. Specifically, when these concerns appears spread out through the code base. This separation of concerns is what is referred to as "cross cutting concerns". AOP provides an API that allows you to write code to address these "concerns" in a desirable manner.

Aspect Oriented Programming (AOP)

Cross cutting concerns are address by way of, what is referred to as, "Aspects". Just as much as an Object models an Entity, an Aspect models a "Cross Cutting Concern". Getting familiar with these concepts takes some time, however as you take the time to write your own Aspects, it will become very easy to follow.

Every Aspect contains an entry point, a Pointcut. This basically describes how is the crossing concern identified. For example, the concern may be "all Constructors calls (from a specified package) must passed through an Authentication process prior to instantiation". So, the Pointcut will be all "calls to the Constructor within the package in question". This Pointcut description, interestingly enough, is one of the reasons where Spring AOP couldn't help me (Spring can not manage objects that are created somewhere else - e.g. Hibernate's Proxy objects). These Pointcuts delegate processing to a handler called Advise which is where most of the logic occurs. An Advise reflects the concern that is trying to be addressed. Continuing with our previous example, the Advise will be "before calling the constructor call check authenticating roles else throw an exception". Additionally, an Aspect may have multiple Pointcuts and each Pointcut will have a minimum of one Advise.

AspectJ

In the Java Programming language, AspectJ provides the ability to use these concepts in terms of objects. In general, AspectJ is an extension to the language. Originally developed by Xerox-PARC, it is now maintained by the Eclipse Foundation. The following code in AspectJ reflects the sample we have discussed thus far (for an object class name Foo):

public aspect AuthenticatedConstructorAspect {

pointcut constructorCheck() : call(* *.Foo());

before() : constructorCheck() {
// Do some coding (e.g. throw an Exception, etc)
}

}

Conclusion
In general, aspect oriented programming provides a great strength to your development efforts if used appropriately. It can become a strong part of your development efforts if used properly and can scale well since it can be plugged in as a requirement is enforced.

References

1. http://www.ubookcase.com/book/Addison.Wesley/Eclipse.AspectJ/
2. http://www.sable.mcgill.ca/~hendren/AspectJ.html
3. http://www.stepwise.com/Articles/AspectJ/index.html
4. http://www.eclipse.org/aspectj/doc/released/progguide/language-joinPoints.html
5. http://www.javaworld.com/javaworld/jw-04-2002/jw-0412-aspect3.html