AOP use cases

[Daniel Dittmar]

John Roth wrote:
>>>When you're supporting a monolithic proprietary application,
>>>sometimes you have to do what you have to do, but today
>>>the entire idea simply smells of a high-tech way to do
>>>ad-hoc patching where a really well designed application
>>>would not need it (and I don't really care if the design is
>>>up front or emergent.)

AOP is not about patching existing programs/libraries. This is just the 
way it is usually implemented in Java.

Other approaches used for languages like C++ use code generation. Code 
generation isn't as nifty and doesn't work as well for Java as Java 
hasn't got a #line directive to guide the debugger. But it's You Can See 
What You Get.

AOP grew out of the observation that an evergrowing percentage of the 
code of the average method is taken over by parts that are not related 
to the main purpose of the method, but by logging, sychronization, 
transaction handling and other stuff.

This kind of code is often of the boilerplace kind, which lends itself 
easily to code generation. And it requires often some context 
information, which must then be passed either through parameters or 
through objects, adding to the line noise that distracts from the 'real 
code' of the method.

And the 'we do this through refactoring' argument ends where you use 
external libraries unless you want to fork them.

Daniel Dittmar