A as in Agent?

I'm not sure if you remember, but back in 1993 or something like that, AOP meant Agent Oriented Programming, and seemed to be interesting and important technology. In the last few years I think it's more common that the acronym means Aspect Oriented Programming instead.

I've heard about AOP (meaning Aspect from now on in this blog post) from time to time during the last year or so, but every time I got interested, something happened that made me forget about it. One thing was this blog post written by Craig Andera where he (and Tim Ewald) states that the declarative services of COM+ just don't work, and the same goes for AOP too.

Another example of a showstopper is that AOP was often talked about in the .NET community as what could be done with interception. Interception is, er, problematic right now in .NET. As I understand it, Microsoft recommends that we don't rely on interception based on ContextBoundObject or the channel sinks in remoting due to future changes.

The other day I met Rickard Öberg at a workshop and he renewed my interest in AOP. For one thing, Rickard taught me that interception (or advice, as it is called in AOP language) is just one of several different mechanisms. (The others are object fragments and introductions. Here is a nice introductory article.). Rickard isn't just using AOP for the ordinary tracing and logging examples, but also as a solution for adding behavior to the Domain Model, for example. The more I thought about it, the more I wanted AOP, not as solution for all possible problems, but as an additional tool in the design toolkit.

I'd like to have more of what Rickard talked about in .NET, for example so that I could add behavior to classes from a smorgasbord (fewer dots in this spelling of the word compared to the Swedish ). I'd like to be able to add one more method to a group of my classes just like that, and two more methods to some other classes, and so on, and so forth. (BTW, this mechanism is called introduction, or mixin, in AOP.) It's like extreme composition , but without paying the cost of duplicating interfaces and implementation/delegating code on the class that is wrapping the other class.

One important thing that object-oriented design is about is separation of concerns and fulfillment of the Single Responsibility Principle ([PPP] by Robert C. Martin). AOP seems to be very much about that.

While we are at it, Martin Fowler wrote an interesting blog post about AOP the other day here. There are no problems with future versions of the .NET framework when using that interception technique.
I plan to put this very technique into practice in a certain project shortly. I think it will provide a clean solution to a problem in this particular project. (This sounds a bit cryptic, but I think I can come back and talk about it at a later date.)

Sure, I think I can see some problems with AOP. If there weren't any it would be really strange, wouldn't it? A tool without any problems whatsoever...? :-) One problem – and perhaps the most serious – is that it makes the code less clear, because at run time there might be more code executed at certain points in your methodäs bodies. To a degree, that can probably be dealt with by smart editor support. Another problem is compatibility and timing issues of different aspects that are weaved together in unexpected ways. Unit testing deals with this problem to a certain extent.

Frans Bouma asked for Multiple Inheritance (MI) support in .NET here, but it doesn't seem as if Microsoft will be giving us this. But I think Frans would like AOP as an alternative solution instead of using MI. What I think Frans was asking for was mixins. That could be solved by MI, but just as well by AOP. Actually, I think this composition-like solution by AOP would be better! (How the AOP mixin is actually solved under the hood – MI, code generation or what – most often that isn't really important.)

I have mentioned so many irritatingly smart people in this blog post and there have probably been more than enough, but I really feel I need to mention two more. John Lam wrote here a similar blog post to the one I have just written - unfortunately he wrote it several months ago. I heard Ivar Jacobson say at NRUF that he is working in the AOP arena right now; possibly he will write a book about it soon.

OK, I'd like to end this blog post with a request to Microsoft. Could we have full-blown AOP support in .NET, please?

Update (2004-02-08): Rickard addresses here some of the problems with AOP that Craig mentioned.