By Sean Corfield
As if we don't have enough three letter acronyms in our industry, the Java community seem intent on inventing ever more of them to confuse and confound the lay programmer. AOP stands for Aspect-Oriented Programming and is considered a very "hot" topic in the Java world. I had read several articles about AOP but had not really "got" what it was about until Chris Scott explained it to me a while back. Since this is such an alien concept for most ColdFusion developers, I was particularly interested in attending his talk on this topic at cf.Objective(). Chris started out by explaining what AOP is really about and why it is useful; he said that there are a number of "far reaching concerns," like security and logging, which are normally sprinkled throughout your application code but are not part of the application's core business logic. These "aspects" of your application cause code duplication. (For example, the logging code would be added to your application in many places.) In addition, the distracting non-business code mixed in with the business code makes it harder to maintain your core business model. The idea behind AOP is to abstract these "concerns" out of the core code and somehow apply them after the fact. In order to make this more comprehensible, Chris discussed a design pattern called "Decorator". This is a standard way to add functionality to an object by creating a new object with the same API (set of methods) that wraps the original object. Each method on the new object typically calls the corresponding method on the original object but also performs other tasks, enhancing the functionality of that method. The problem is that a decorator is tied to a specific object, making it a fairly labor-intensive task to add new functionality such as logging; every object needs to be duplicated, and each duplicate object must be written to perform all of its methods as well as the additional logging functionality. The decorator pattern was used later on in the presentation, in Chris' AOP example. The main difficulty in learning AOP is the dizzying array of new terminology and Chris took us through that one piece at a time. The core AOP concept is "advice" -- functionality that is independent of the object to which it is applied. For example, given a method name and some arguments, we can easily write a logging function without knowing anything specific about the object on which the method is being called. Then we have an advisor -- an object that knows how to apply advice to the desired methods -- and a proxy factory which essentially builds a decorator object for each specified object. The end result is a new object (created by the proxy factory) that looks just like your original object, which applies the necessary advice before, after or around calls to the original object's methods. Chris dug into some more of the terminology and then walked us through a couple of examples that made things much clearer. He showed how to use the basic AOP features of the ColdSpring framework to add logging to existing code without changing the existing code. The example seemed quite complex because several cooperating objects had to be created just to apply this small piece of logging advice. Then Chris showed how ColdSpring's main functionality -- management of CFC creation -- can be used to simplify the AOP code. He added both logging and caching to an existing application, again without changing the underlying code, by creating independent CFCs that knew how to perform logging and caching. He then wired things together using ColdSpring's XML configuration file. It was an impressive example! Chris closed out his presentation by showing how ColdSpring can help build Flash Remoting applications. By applying the principles of AOP (in this case, abstracting out data type mapping, which is non-business code, into an "advisor" object), ColdSpring can automate the creation of a proxy for your business model that exposes methods remotely and manages the conversion of data types between ColdFusion and ActionScript. I think Chris lost several people in the audience at this point, as the demo was a little hard to follow, but he definitely conveyed the power of both the ColdSpring framework and the techniques of AOP itself. Though I had experimented with ColdSpring's AOP functionality before the conference, Chris's session cemented the concepts for me and helped me understand some of the examples I had looked at earlier. This was probably one of the most advanced sessions at the conference. Whilst a challenge for many people, I think it really helped raise the bar in terms of what we consider possible in ColdFusion programming.