AOP use cases
Daniel Dittmar
daniel at dittmar.net
Sun Apr 18 15:34:37 EDT 2004
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
More information about the Python-list
mailing list