Why is the Interceptor pattern != AOP

[Gavin Bong]

Read ted neward's rant
Do you think that Interceptor pattern (e.g. Dynamic proxies) is considered to be AOP ? In my opinion, even servlet filters should be considered a variant form of AOP (i.e. you're not intercepting & injecting code on method calls but on URL requests).

[Lasse Koskela]

Personally, I never understood why people are ranting about the subject. To me interceptors are AOP and filter chains are AOP, but not the other way around. On the other hand, I couldn't be bothered to read all those rants so I may have missed the rationale behind them.

[Michael Zalewski]

I think dynamic proxies are a good way to think about aspect programming.
But I also think aspect programming is more powerful. Usually, when you write a dyamic proxy, you will have to change the proxy if the proxied class changes. And you usually proxy only a single class at a time.
An aspect can have several cutpoints across multiple classes. An aspect does not need to be recompiled when new methods are added to the base class.

[Valentin Crettaz]

Much as object-orientation provides support for encapsulating "commonly localizable" concerns into objects, the aspect-oriented paradigm provides a mechanism, called aspect, for modularizing crosscutting concerns. The three fundamental concepts of aspect-orientation are:
- the join point model that allows one to potentially select any execution point of a system
- the ability to add aspectual behavior at the execution points identified by using the join point model
- the support for structural amendments in order to modify the static structure of a system.
AspectJ provides all of the above points:
- the aspect construct enables one to encapsulate crosscutting concerns
- the pointcut construct allows one to select any execution point in a program
- the advice construct provides support for adding aspectual behavior at specific points in the execution flow of a system
- the introduction mechanism provides for structural amendments.
The Interceptor pattern is well-suited for identifying execution points and adding behavior at those points. However, it does not provide support for modifying the static crosscutting structure of existing software. This is what makes the main difference between the Interceptor pattern and AOP. Therefore, we can say that the Interceptor pattern provides support for certain concepts of AOP, though not all of them.
[ September 18, 2003: Message edited by: Valentin Crettaz ]

[Gavin Bong]

Therefore, we can say that the Interceptor pattern provides support for certain concepts of AOP, though not all of them

Thanks Valentin. That is very clear. But I dare say that frameworks will offer different degrees of AOPness (AOP lite, AOP standard, AOP with dotted i's and crossed t's) and that is fine. As programmers, we will just match the problem with the right or adequate tool.

[Ilja Preuss]

Notice that a similar rant is often heard from seasoned procedural programmers regarding OOP. The argument is that you can get the same form of decoupling, encapsulation etc. in a language like C - which actually is correct.
But the point is the syntax of an OO language makes it *so* much easier to apply OO principles that it easily becomes the natural way to do things, instead of being only applied in special cases. I guess the same could be true for AOP.