…an aspect can alter the behavior of the base code (the non-aspect part of a program) by applying advice (additional behavior) at various join points (points in a program) specified in a quantification or query called a pointcut (that detects whether a given join point matches).This offends my sense of what is good modularized code. AOP is done under the banner of "Separation of Concerns" but instead of separating parts of programming code in simple and visible ways, AOP is coupling it tightly. AOP is coupling code modules in ways a programmer would not expect from viewing the affected code. This is tight coupling of the worst kind. In my earlier posting on coupling I rated types of coupling from 0 to 14 from loosest to tightest. I will call this type coupling "code coupling" and give it 15, the tightest coupling index of all. The coupling is through the code rather than through data passed to the module. Code coupling is not new but I did not expect it to come up as modern programming paradigm.
Another form of code coupling is "inclusion coupling" which is explained well by Milind Shingade
Inclusion coupling is a form of coupling in which one component includes source code of another component. If the included component changes something on which includer depends or adds something that raises the conflict with something in the includer then the includer must change.I see inclusion coupling as more benign than using AOP but I will still roll it into my "code coupling" category.
Control Coupling (coupling index 12) is pretty tight. This is where you pass a Boolean or control parameter to a procedure and have code in that procedure which checks the value and executes different logic based on that control parameter. This is one way of affecting the executed logic in the procedure but at least you can read the code and have some expectation of what the behaviour is going to be. With AOP an unsuspecting maintenance programmer may not have any idea that the program code is being affected by an "aspect".
Unfortunately I have to grant there may be a place for AOP. Code for auditing, logging, exception handling, security and range of routine work that needs to happen along with the business logic can make it difficult to discern the main thrust of what program code is trying to achieve. There is a big need for control and proper governance of AOP. If it has to be used then only senior developers should implement the Aspects. It only should be used in very limited circumstances. Ideally there should be clear documentation in program modules affected by an Aspect.
This should not be a pervasive programming paradigm. The programming should not be Aspect Oriented at all. Code should normal, good Object Oriented code but if AOP is supported a developer may introduce one or two Aspects to influence this code.
In summary I think AOP may be a horrible necessity in some programs and should be used with extreme caution. AOP has given me another type of coupling to add to my list. I had expected the next entry to my coupling list to be in the looser coupling range. I recently listened to a Podcast from Jim Webber of ThoughtWorks. Jim claims that MEST uses looser coupling than WSDL. I would like to see that. I am hoping to blog on this soon.
4 comments:
I agree. AOP isn't worth the name. It's just a kind of pattern, if not a junk.
Thought provoking, well written.
what about annotations? I think they are worst than AOP, out of nothing POJOs got coupled with hibernate annotations, spring annotations, java annotations and custom annotations.
I find the concept of AOP being non-modular as laughable. AOP was created directly to address modularity when not otherwise possible in OOP. That doesn't mean that AOP is fool proof, as improperly designed aspects can be just as likely as improperly designed objects. There are concerns that are truly crosscutting in OOP that cannot be modularized (aka design decisions that cannot have their implementation encapsulated in a single location). An example would be an implementation of the observer pattern within an OO program. The existence of the OO pattern implies that OO design cannot modularize it natively, yet this can trivially be modularized using AOP (see AOP tutorials).
You'll note that the creators (authors) of AOP have direct academic inheritance from the creators of 'refactoring' (modifying code to make it more modular without changing any functionality) and modularization of software systems.
Post a Comment