AOP's value lies in producing uncluttered code through a separation of concerns. Point cuts and related advice are coded separately from the places where they will be applicable, and are weaved into the instruction stream, typically at runtime. One of the first thoughts that I had was about a programmer's understanding of the functionality of a system designed and coded using AOP. How does a programmer understand the functionality and the flow of a program when they are distributed across different files with nothing to relate them? I had raised these questions in a review I once wrote for an AOP related paper.
The answer is that a programmer doesn't need to understand the functionality of the entire program; if concerns are well-separated, then he need only understand the code that implements the functionality he is responsible for, possibly in conjunction with other programmers who are also responsible for that functionality. You will notice that I am, more or less, equating functionality with concern. An advice can be weaved in one concern only by another concern. A programmer doesn't need to care what advice is being weaved by other concerns, that being the whole idea about separation of concerns.
In the Jan/Feb 2006 issue of IEEE Software magazine, there appears an article about AOP in the point-counterpoint section. The counterpoint argues that unlike hierarchical design, AOP obscures the understanding of a software module. I don't believe that is the case for reasons outlined above. I view AOP as sitting on top of hierarchical design with various aspects as peers. (Perhaps AOP itself can use some hierarchical design concepts as it matures). Another argument made against AOP is that it is hard to identify non-trivial aspects. Most examples describe rather trivial aspects such as logging, profiling, and synchronization. I find this argument valid. However, I believe this to be just an initial hump which will be overcome as systems designers get used to thinking about in terms of aspects. To conclude, I agree with its detractors to the extent that AOP has yet to prove its value, but I also agree with its supporters that it will see widespread adoption.
BTW, the paper I reviewed did not achieve a separation of concerns. In such cases, understanding program behavior would be a challenge second to none.
