I’ve decided it’s time to figure out if aspect-oriented programming is worth, well, figuring out.
So far, nearly everything Google can find for me about AOP is positive — glowing, even — and that makes me nervous. Real change is supposed to be painful: even today, when object-oriented programming has become dominant, it is easy to find critics; XML had, and still has, many detractors; and any self-proclaimed guru standing in a Starbucks line can tell you what’s wrong with HTML and the web before the barista has time to finish making a cappuccino.
Does the lack of criticism mean that AOP is practically perfect in every way, or simply that people don’t care enough to pick it apart? After reading some online introductions and studying the AspectJ syntax and tutorials (with their seemingly endless trace and log examples), I can see how the approach might have some benefits, but I’m not convinced that the benefits outweigh the potential code obfuscation.
In fact, one of the few critical pieces I did find, a two-page University of Passau paper entitled AOP considered harmful (the paper later spawned a $250 business research paper), compares AOP with the notorious GOTO statement from early procedural programming languages, attacked by Dijkstra in his classic 1968 letter Go To Statement Considered Harmful. In addition to GOTO, AOP also reminds me a bit of C macros, another cause of confusing, hard-to-maintain code.
I’d be interested in comments from people using AOP (AspectJ or otherwise), as well as pointers to other sources that are not simply hyping the movement. Does AOP work for you? I’m skeptical, but I’m not willing to dismiss it yet.
Quoderat 
I think my take on AOP is exactly like yours. If you get any responses through channels other than blog comments, or find other sources of information, please share them.
Pingback: Anonymous
I’ve been advocating the *careful* use of AOP for a few years now. I’ve even written a book on the subject, see http://www.aspectjcookbook.com. In my opinion, aspects offer a fantastic way of enabling even higher degrees of loose coupling within your applications. Lets face it, the tighter coupled your software’s components are, the harder things are to change. Carefully designed aspects can actually offer a more natural representation of your users requirements (see AOP and use case book from Ivar Jacobson) and I’ve found that this affects the very architecture of my software; far from the regular “Aspects do logging/tracing/security” hello world examples that you’ll find all over the place.
A quick word of warning though. Aspects are powerful (particularly in heavyweight AOP implementations such as AspectJ), but with that power comes responsibility (doesn’t it always). A badly design AOP solution is no better than a badly designed OO solution; in fact it can be even worse.
There seem to be two schools of AOP implementation- The compile-time version relies on pre-processing your source code to include the appropriate methods. The run-time version (Spring is the one I’ve looked at) uses proxy objects as wrappers around your classes and methods.
The compile-time version does seem to me like CPP macros; on the other hand, you can be sure that you won’t get huge variations after you’ve passed your unit testing. The run-time version seems cleaner, but seems like it has the potential to introduce changes in your application’s behavior at runtime, once it’s out in the wild.
I buy a lot of the argument that it makes sense for cross-application concerns, but I don’t know how many concerns there really are: Logging, Security, and possibly performance monitoring seem to be about it. Anything else seems not to be global enough to be worth the trouble.
Perhaps that’s why aren’t complaining about it so much? Maybe everyone is being awfully conservative with rolling it out…
I totally agree that AOP adoption has been pretty conservative (to say the least :). But I’ve also found that the biggest problem seems to be that AOP is seen as dealing with a specific set of cross-cutting concerns only (that would be the logging/security/caching type of group).
But aren’t use cases another form of cross-cutting concern? When you start to think about your software’s architecture in those terms you can start to really apply AOP in a more general fashion and, in my experience so far, that’s where the design really starts to benefit.
I’ve looked at AOP a fair amount and have used it in a couple of proof-of-concept projects (I’ve used AspectJ). Aside from the additional compile errors and warnings that it allows you to define, most of what AOP seems to be providing is a (somewhat sneaky) means to introduce multiple inheritance. To my mind, it’d be a lot easier to ‘sell’ to people if it would use the normal Java syntax for classes, instead of the ‘aspect’ stuff, and some supplementary syntax (which they have) to describe how to apply the overridden methods to those in the base class (the before/after/around stuff). Large parts of AOP remind me of CLOS more than anything else….
I mean, most of what an aspect is is another base class that the advised classes are inheriting behaviour and/or attributes from, in addition to the one that Java allows them to.
I have been using AOSD concepts and tools for several years now in my work as a consultant and I find them incredibly useful.
That said, I find the AspectJ school-of-thought and approach to be completely over-hyped. Most people who advocate it do not know how a commercial project works and those who do seem to have vastly different projects than I have had in the last 7 years… so different that I have a hard time recognizing them as the same thing.
Conceptually, AOSD, not AOP or AspectJ, is a great approach, but the currently available tools, of which AspectJ is the most prominent one, do fail in a variety of places. I actually wrote a blog entry about that, but this is no plug to do some self-advertisement (http://www.jpmdesign.net/wordpress/2005/08/04/aspectj-where-to-improve/).
If you intend to look at AOSD and wonder whether it’s worth it, I can only suggest looking at the AOSD mailing list (at aosd.net) and skip all the “I don’t know how to do this in AspectJ” questions which should never have been posted to that list anyway.
As for the comment from Brendan McKenna: “To my mind, it’d be a lot easier to ’sell’ to people if it would use the normal Java syntax for classes, instead of the ‘aspect’ stuff, and some supplementary syntax (which they have) to describe how to apply the overridden methods to those in the base class (the before/after/around stuff).”
AspectJ is using this kind of language extensions and they have been criticized for it. Other AOSD approaches (Hyper/J, CME) do not do that and offer support beyond the mere code level (Concern Models, like Cosmos).
As for the comment by Russ Miles: “But aren’t use cases another form of cross-cutting concern? When you start to think about your software’s architecture in those terms you can start to really apply AOP in a more general fashion and, in my experience so far, that’s where the design really starts to benefit.”
Yes, you are correct. And AspectJ fails in this area. Concern models do provide some support here as do some approaches to bring AOSD to the architectural languages (can’t find the reference just now… It was at the last AOSD). Unless AOSD tool support truly supports all phases of the development, it will die off as a quirk.