The ServerSide has an interview with Kiczales and an accompanying Threaded Discussion. Worth a read for anyone wanting to know the thinking that has gone on in the AOP world. (Kiczales has been previously mentioned on LtU in relation to MOP/AOP).
Posted to OOP by Chris Rathman on 7/28/03; 2:27:58 PM
Kiczales makes a lot of using "examples where it is appropriate to use AOP", but I've never seen any that were compelling enough to risk the "macro-factor" (hidden behaviour that is hard to reason about).
Kiczales et al. have been successful in making me feel that I might be a Luddite late adopter here, so I'm wondering: Are there any AOP converts here who could explain to me the error of my ways? ;-)
Whether that is so or not, an interesting side-effect of doing TDD has been, for me at least, to reduce the problem that AOP is trying to solve in the first place. I'm finding I actually use inheritence less and more effectively, and using straightforward delegation and object interaction more to solve the modularity of concerns.
By changing my approach to design and programming I have solved those problems simply and robustly without having to resort to the strong medicine of macros or a preprocessor of any kind.
At any rate, I have been wondering if AOP isn't a bit of the Emperors' New Clothes. Perhaps some industry pundits who have made their names converting people to OO, now need the next bandwagon to champion (e.g. Grady Booch)
But I could be wrong. ;-)
For concrete examples, I'd suggest taking a look at what JBoss uses AOP for. COM+ uses a limited form of AOP, where the interception is hard-wired into the COM framework itself. The point in both cases is to enable a component container to provide configurable services related to things like persistence, transaction processing and security - fairly classic examples of "cross-cutting concerns".
I've not yet seen a really convincing demonstration of the power or relevance of AOP outside of this domain; which leads me to wonder whether it's really a question of introducing a new "orientation" into the world of programming. I don't think that the problem it purports to solve exists at all in any language which has higher-order functions and combinators: the problem is really that the mechanisms for gluing classes together in most OO languages are so limited. If you view AOP as a technique for class composition, you might end up wondering whether there are still other ways of composing classes besides inheritance and the identification of "point cuts", and why such composition isn't easier to do in the language itself.