From a recent discussion on the merits of AOP on the TSS:

From those results, I could come to the following conclusions:-AOP is the best way to patch the original code they had-'Hacked' Java out performed the AOP solution (which is why I believe they added # of images created to strengthen their AOP argument), yet they could still tweak the AOP implementation and beat the 'Hacked' Java version.-Their AOP solution could have just has easily been modeled in Java in an OO way using pipes/filters, and java.io.*-like implementations.-AOP introduces another learning hurdle into the maintenance of the program by other programers-- K.I.S.S.In summary, while the AOP solution worked, you could have just as easily modeled the same solution in straight Java using stateless filters and pipes. The 'fusing' optimizations they are talking about with AOP could easily be modeled in OOP through dependencies/comparators within a pipe of transformations. I don't think you can necessarily say that an OOP solution is ever better than an AOP solution, but why introduce it if you don't need to?

All good points. The main problem is that the AOP community has not focused on the Why, but rather too much on the What. We tried to focus on the why in JBoss AOP's The Case for Aspects user guide.

I think AOP will first be used by the framework developers to make coding easier for framework users. The masses won't know they're using AOP, but using the framework will be butt-simple. From this, the framework developers will discover design patterns. The users will learn from these patterns and be able to apply them to their code. It is a natural evolution.

AOP + Annotations is a perfect example of simpler design. It allows the framework developers to easily encapsulate the functionality their annotations are supposed to introduce without relying on messy unmaintainable code generation (I've written an IDL compiler, so I know what I'm talking about). Users get an easy way to apply these annotations. They just tag their code and use it.

A perfect example of AOP + Annotations is the Asynchronous Aspect Clause Haussenet contributed to JBoss AOP. You tag a method as @Asynchronous which introduces an advice that runs the method in the background, and a mixin that allows you to access an API to get the response of the method asynchronously. I've recently extended this to work remotely. Clean encapsulation of asynchronous behavior combined with the ease-of-use a middleware user expects.

JBoss' EJB 3.0 implementation is based entirely on JBoss AOP. The aspect-oriented design has given us a container that is completely extendible.

JBoss Cache is another example of a framework using AOP for its design internally. They needed to aspectize their code because it was becoming too bloated. And also used AOP to provide transparent caching to their users.

One large problem with AOP is that the ordering of advices is critical in applications of it. For instance, the Asynchronous aspect needs to come before transaction demarcation, but after security. This is where IDE integration can be very important as you need to see what aspects are applied to a specific joinpoint and what order they are in. Advice ordering, IMO, is the one significant hurdle that may make AOP hard to adopt in many situations.

All and all, I find the HUGE adoption problem with AOP is that its hard to understand by reading about it. You need to see examples before you make the connections. Maybe OOP had the same problem. I can't remember back that far.

Another interesting discussion was as follows. Somebody posted this:

OO is not the end all. Different ways to solve different problems. AOP and OOP are not mutually exclusive.

To which an opponent of AOP replied

Correctly used, the two are fairly mutually exclusive. It would be improper to write a whole domain model in aspects or declare all of your intrinsic business behavior in aspects.

I agree with this statement in principal that it is probably incorrect to use aspects to model your domain model, but...Last week I had an interesting dinner meeting with a JBoss user. He was telling me that he scopes out the easy, simple, monotonous work to his offshore team and is starting to use AOP to weave in the more complex stuff he needs to write that the offshore team can't handle. I'll have to get back to him a few months from now to see if this approach was successful. Gotta admit, I'm skeptical, but it is an interesting thought.

Anyways...Thanks for reading this really long post.

Bill