Kiss My App

Wednesday, November 17, 2004

I have an AOP Framework for You

Today I came upon a new AOP framework that performs 5 times faster than the next implementation. It allows type safe mixin's, decorating interceptors, and can be easily run in any debugger. It's called 'Java'.

I've been writing code for my company long enough that I'm now running into those, "now why the hell is it doing that?" situations. What gets me through the learning curve is my trusty IDE with it's wonderful 'goto Definition' features, and not to forget the 'find References' gem. It's the only weapon I have in refactoring.

Now developers are all over AOP. Here's a great idea, we are going to make all of our classes dependent on a framework which will sprinkle your objects with behaviors that you will only get at runtime. Many articles talk about how to add things like debugging to your method calls using some AOP framework. If you didn't depend on running your code in an AOP framework in the first place, you could just debug what you did in any IDEs' interactive debugger.

AOP also talks about Mixin's, a way of weaving additional static behavior into your objects. Hey, I just made your car object a boat and the rest of your code doesn't even know it yet! How cool is that?! Java has Mixin's too, it's done through the composite pattern and interfacing your objects. I know first hand, that developers scoff at the need to interface all of your business objects, but even AOP implementations like Cglib of DynaOp use interfaces to represent mixin's. Yay, we have type saftey... kinda.

In addition to Mixin's, there are interceptors. I'm going to back pedal a bit in my rant and say that I can see the benefits of interceptors, but only within a framework context. Servlet Containers use Filters along with SOAP frameworks, but those are there to provide you with behavior that is contextual to the protocol. Some developers use AOP to handle transaction, I say use ThreadLocal or use the Transaction/Command/ServiceLocator pattern to define a flow of events for a transaction.

I can see how AOP can help us programmers be more lazy, lazy programmers are the best programmers hands down. Really, who wants to write the same code over and over? They will do it right the first time so they won't have to do it again or change it. But let's be good lazy programmers and follow Agile principals. Things like Single Responsibility, Composite Pattern, Delegate Pattern, etc should easily prevent you from coding yourself into a corner on your next project. e.g. I mentioned Mixin's using the Composite pattern, why not plug your Composite objects into an IoC container? There's your AOP framework, and you should be able to new your composite object in a main method too in order to test.

Once you start thinking in AOP, then your implementation and design will degrade since you know you can shortcut your way out of anything into an un-traceable mess. Go ahead and use AOP on your next project, then come back a couple years later and try to debug it. Let me see where the heck that value is being set...


Post a Comment

<< Home