Kiss My App

Sunday, November 28, 2004

Ego Tripping at the Gates of Hell

In my initial rant about AOP, I hoped to spawn some serious debate from the Java community over what and how AOP should be used, if it at all. Two very lengthy threads insued at and Sun's Java Forums. I was offered some good examples of AOP usage, some poor examples of AOP usage, and an abundance of hubris comments. To all I say, "Thanks!"

I spent some time reflecting on my original post and the examples/debates offered up on the forums. Not to spoil the ending for all of you, but I feel even more strongly against using AOP with OOP than before.

Both OOP and AOP work to solve the same thing-- encapsulation and inheritance. The difference is that OOP provides a vertical object model through inheritance and delegation and AOP provides a horizontal attribute model through pointcuts. When a developer writes code, he or she operates within a set of 'rules' as specified by the language to provide scope to the logic they convey in their code. By providing scope, code becomes easier to read and maintain-- you can logically focus your attention on a single scope of variables and state through the concept of objects. AOP advocates are correct in stating that aspects can provide the same kind of scope and encapsulation, but one is better than the other.

Point #1, who has the right to provide the behavior for an object-- the subject or the observer? An example is moving and displaying a collection of shapes. When a caller (the observer) calls methods to modify the state of the shape, does it have the right to notify the display that the shape has actually moved? Shouldn't the shape (the subject) be able to retain the knowledge of if and how it moved? What if shape's behavior changes, will the observer's behavior now have to change? The OOP solution for updating the display would be to let the shape notify any listeners that it has in fact moved. The AOP solution is to update the display any time I call a method on shape where I think it will cause it move. Compile-time weaving or not, we've just broken the shape object's encapsulation and added code to our system that has to be maintained seperate from shape itself.

Point #2, AOP can make OO code act in unnatural ways. JBoss AOP provides an 'asynchronous' annotation to methods. The idea of taking a method and by simply adding an annotation, have it be asynchronous for everyone that uses it (the callers). First off, the method probably wasn't meant for asynchronous operation and the caller doesn't necessarily have the right to now declare it as such. Secondly, the JBoss asynchronous aspect introduces code changes to the way all callers now interact with the method. If the goal of AOP is to encapsulate behavior, this aspect is a complete 180. Referencing my first point, through AOP we've just changed the behavior of the subject through observation. An OOP solution would be to delegate the call while providing a literal asynchronous method signature, encapsulate asynchronous implementations in your delegator. If I want to use the method as written, unmodified, I can still call it directly. If I want the method to be called asynchronously, then I can be the special case and use a delegator.

Point #3, AOP with OOP now creates a bidirectional inheritance model. What does that mean? Your code can now be a pain to maintain. That is probably the biggest issue AOP proponents had with my original rant. Developers now not only have to trace the vertical object model, but also the horizontal attribute model as provided by aspect pointcutting. Developers everywhere are asking themselves, "Where's the beef? Where's that behavior coming from? Where's that variable being set? I don't know!" It might just be an IDE issue to some, but to me it's a logical issue. I can logically follow a single java class on a piece of paper, I can't say the same for all of the aspects that might be weaved at compile or runtime.

In summary, where do I see any benefit to AOP? In decorating my code, not my application. This means that AOP can be used for things like logging/tracing the code I write, but never to dictate application behavior or state. It really has no business in my application. If you find AOP as a wonderful solution to issues during implementation, then you are going about OOP the wrong way. The only thing AOP does is provide encapsulation for procedural programming.


Post a Comment

<< Home