AOP Why? When? Where?

The other day, I attended a Chicago Java Users Group (West) presentation titled "Aspect-Oriented Programming and Software Design in Java and AspectJ" by Dean Wampler. I had a number of burning questions on my mind before I went there:

1. Why invest time learning AOP?
2. When do we need to apply AOP?
3. Where in our code do we apply AOP?

Well, the answers that I got go as follows:

1. AOP helps separate mixed concerns that OOP cannot. For example, OOP does not have an easy mechanism to separate the transaction concerns from your business domain logic. AOP on the other hand can handle that transparently or provide developers with an annotation to apply on a method when a transaction is needed.
2. We need AOP whenever our code is becoming unreadable and hard-to-maintain due to intersection of many different domains, such as the business domain, transaction domain, security domain, logging domain, and others.
3. AOP is applied at the points of domain intersection, usually keeping the business domain code in the main application classes, yet separating code from other intersecting domains into applied aspects. So for example, the logic for "checking if the logged in user has access to the task they are executing" can be separated out into its own aspect outside the business domain code.

Next, I had a concern about how long it would take all the team developers to learn AOP before being able to reap its benefits. After all, AOP seemed to have a learning curve that is as steep as OOP's.

Well, here is one pattern that can be followed to start reaping AOP's benefits before everybody on the team has caught up with it. Have the first developer or two generate Java annotations that embed useful aspects (like a transaction annotation, method logging annotation, or security authorization checking annotation), and then provide it to the rest of the team for free use wherever needed. This will give the team a chance to learn AOP gradually and still reap the benefits while doing it.

Next, I wondererd how do you introduce AOP into a team with success?

Well, simply start using AOP to improve your development processes first. For example, use AOP to check your code at compile time for any violations of MVC principles (is the View talking directly to the database or is it going through the Model tier first?) This will help the team get acquainted with AOP without the risk of releasing malfunctioning software as AOP is only used for development purposes.

Last but not least, what are some of the recommended AOP libraries?

1. Spring AOP
2. JBoss AOP
3. AOPAlliance (comes with Guice)

One note is that many AOP features are sort of built into Ruby, so Ruby developers rarely need to use AOP formally. The "begin" and "after" hooks in Rails controllers are an example of AOP.

If you are currently using AOP or have utilized it in the past, please let us know how things went and what benefits or drawbacks were reaped.