Hi,
Just curious as to when people choose to use AOP v Custom Interceptor Points. It seems to me that custom interceptor points allow you to write code in an EDP way, which has a certain amount of cross over with AOP. Would appreciate hearing people’s experiences and thoughts on which to use and when.
Thanks 
Hi John,
Here is my take on it.
Custom Interception Points: These might be similar to AOP chains, actually it uses the same pattern internally to be built. However, I find these are more to promote event-driven paradigms than true aspect oriented programming. The majority of usage we find in custom interceptors is to provide extension points for software by announcing events and then listeners can extend those points as they see fit. We have done a great deal of work with ColdBox custom interceptors even to the point where you can use them as workers and asynchronize them. AOP is more granular as its point of origin are CFC methods. Thus, they have a higher point of impact on granular code and thus decoupling OO code that has cross cutting concerns with other OO pieces of code. I find myself saying that AOP is OO evolved as it is dynamically mixing functionality for a higher purposes. You decouple your software so you can couple it again at runtime instead. I mostly use AOP when I want to apply different pieces of code to more than 1 are of my objects in a similar stamp fashion. I find it very specific and more like growing functionality ontop of each other in contrast to the custom interception points where I am mostly using to extend via events and even produce content elegantly in an application.
Hopefully, I didn’t babble
Luis F. Majano
CEO
Ortus Solutions, Corp
www.ortussolutions.com
ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com
Hi Luis,
Thanks for the reply - not babble at all
I’ve used both, but am interested to know how others approach it as I always looking to take advantage of frameworks to help me write better code.
The way I have been viewing it is that AOP is great when you want to something which is pretty dumb, so logging and also caching (retrieving data from cache and the adding items to the cache is not the specific responsibility of say a DAO so it seems cleaner to me to do this somewhere else) - both of these seem like a good fit for AOP.
Custom interception points is something I’d use when I want the data to be transformed (the idea of AOP being used to ‘auto-magically’ change data just doesn’t feel right to me), or the functionality is affected (for example a security interceptor redirecting a user) or AOP is too simplistic.
Would you say that those are a good mindset as a starting point?
Cheers,
John
specific example.
the modules i use create their own user record (with a FK back to the main user) to maintain module-level permissions.
when a user is deleted on the system, i raise a ‘onDeleteUser’ announcement. any registered modules that hear it, then delete their own user record.
another example.
the API ive written has an intercept point that transforms all the data in the event collection into a JSON package and returned to the user. that way, all the handlers behave as usual and there is only one point in which the data is transformed.
i also use the API’s interceptors to validate the hash, throttling, etc.
Hi John,
One of the things apart from Luis as stated, is that the perception of what they achieve. For example, Custom Interception points are more likely to be used when you want to apply hooks to some modules. For example lets look at logging as an example.
In most cases one would normally do something like this.
public void myHandler() {
log.debug(“log me here…”);
}
Now in some cases, if your looking at expanding on this to allow modular feature sets to clients or even internally, you could add something like this.
public void myHandler() {
announceInterception(“customLogging”,{renderer=arguments.interceptData.oPlugin,CBHelper=arguments.interceptData.oPlugin.cr});
}
This means we send out to anyone who wishes to listen, providing a way to say well for Customer A or Module B, we can apply different logging styles without changing the code, just by listening.
In an AOP way, we are really providing an around handler / function / method to an already existing method. That means it isn’t as portable or efficient as it is actually tied to that ColdFusion Component. Where as Custom Interception points, become transportable and are modular in appearance.
Hope that helps.
Thanks Andrew,
That pretty much confirms where my thoughts are going.
Thanks
John