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...
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...
posted by Jacob Hookom at
4:04 PM
6 Comments:
But I can use OOP inheritance to turn your Car into a Boat as well - add a few methods, make a few others throw UnsupportedOperationException, implement the Floatable interface and off you go.
"But that's improper use of inheritance", you'll say. "It's against OO theory and best practice. It doesn't work and will get you into all sorts of trouble". Of course. And the same is true for weaving or mixing in aspects.
Intelligent critique of AOP is a good and necessary thing - we badly need AOP theory and best practice which is as battle-hardened and robust as that of OOP, relational databases and so on - but I'm sorry to say this is not it. You make the impression that you have never used AOP in anything more complex than a toy project.
For goodness sake, it's just another way of decomposing or factoring your solution (one nicely orthogonal to inheritance), and of course it can be abused. That's not the point. So can OOP, procedural programming and so on. Stop erecting windmills just so you can fight them.
By
Anonymous, at 6:29 AM
This comment has been removed by a blog administrator.
By
Jacob Hookom, at 8:24 AM
I think the Java language is being badly abused in general with too many toy ideas. I'm still looking for a solid example of AOP that isn't simply a toy. I've read the books on AspectJ and AOP (my example was a simple one). But, all of the examples I've read can just as easily have been accomplished through OOP programming principals in the first place.
Where I see AOP as being useful is refactoring code already written within a large project as one big band-aid.
You talk about erecting windmills, I'm sorry to say that AOP is one big windmill that too many people are fighting and will be fighting to maintain. Unfortunately, things like metadata/annotations will probably win out in the long run in order to provide pseudo-declarative behavior to your objects.
By
Jacob Hookom, at 8:32 AM
If you're looking for an example of AOP that's not trivial check out
http://www2.parc.com/csl/groups/sda/publications.shtml
they did some image processing program using AOP that got similiar perform with a lot less complex and mangled code.
By
Anonymous, at 3:52 PM
http://jestate.dev.java.net
use the springframework.
--b
By
Anonymous, at 6:49 AM
Hi Jacob,
When I first read about AOP I thought it was an crazy way to think about code yet alone program using it. Over time I started to see how it can solve problems that could not easily be resolved without it.
For example, we were moving our app from Java 1.3 to 1.4 but we had a class that implemented the Connection interface. Since this interface changed so much between these two Java versions, we had to keep two copies of the same class in the source but disable one depending which JVM we were using.
AOP let me resolve the issue because I was able to move the code that was in our class into the aspect. This worked great for us.
Another instance is when we were told we needed to add a temp feature to one class until other teams were able to support it. We couldn't modify the class since it was generated by a tool and modifying the tool source was too risky since other projects used it as well. We could use the Decorator pattern to modify the one class but then we would need to actually modify a couple of files. Using an aspect would only require us to create the aspect to do the same thing but we would not touch the source reducing potential bugs.
I too see the AOP can be very dangerous and confusing especially when if you have too many aspects effecting the same area of code.
Also talking to other developers and documentation help.
By
Anonymous, at 10:44 PM
Post a Comment
<< Home