This post originated from an RSS feed registered with Java Buzz
by Jon Tirsen.
Original Post: AOP != Interception (sorry, Ted)
Feed Title: jutopia
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: Ramblings on Java, AOP, TDD, agile and so on. some like it jutopic!
Sorry, Ted, I was wrong. There actually was a point to your AOP != Interception article. With some time I've started to appreciate some of the finer points of AOP.
AOP isn't interception as in AOP is interception and more. This is my AOP manifesto, the least common denominator of all AOP systems (well, according to me at least):
Interception As in "not being equal to AOP", also known as advice in the more academic AOP-world. It's basically the act of adding further processing to certain locations in a system. The locations are called points or join-points and an advice(interceptor) is typically applied to a set of points or a pointcut. I'm not convinced much more than method-interception is needed, but that's what is required at the very least.
Introduction Do you remember your first lessons in object-oriented programming? The whole point was to modularize by encapsulating state and behaviour. So if interception is behaviour, introduction is state. Introduction should also make it possible to add further behaviour to an object, but in contrast to interception this behaviour is not interleaved with the existing code.
Inspection This is somewhat a new area for the new wave of open-source AOP, but in some ways runtime attributes and method-names-patterns are in this are. While I don't believe field-interception is strictly necessary I do believe it's necessary to access information on what a methods does, what fields it modifies, what methods it calls, who calls this method, and so on... For example a object-relational framework could load fields from the database before the execution of a method that uses these fields. A transaction could be started if a method is called from the user-interface and if that method is modifying some external resource or persistent fields, directly or indirectly.
Modularization Not only must it be possible to intercept, introduce and inspect, one must also be able to encapsulate it all in aspects. An aspect modularize the entire crosscutting concern (such as persistence, undo, transactions, locking, caching and so on) into one single module (possibly consisting of several sub-aspects, by delegation, inheritance or composition). This could be a Java-class or even... *yuck* XML.
If you ain't got all of this, you ain't worthy being called 'AOP'. :-)
Previous Topic
