AOP use cases

[John Roth]

"Daniel Dittmar" <daniel at dittmar.net> wrote in message
news:c5ul9s$rpf$1 at news.eusc.inter.net...
> 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.

Code generation is an interesting beast. Code generation where I
never have to look at the generated code for normal development
is something I appreciate. Code generation where I have to maintain
my own code around the generated code is an abomination. Since
I don't know how the tools work in C++, I can't comment on which
approach it takes.

> 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.

Bad design is bad design. Having methods with more
than one responsibility is poor cohesion and high coupling.
Spending a bit of time thinking about how to encapsulate
this type of crud will pay big dividends. Unfortunately, it
won't get academic publication credits.

> This kind of code is often of the boilerplate 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.

Duplicated code is duplicated code, and should be ruthlessly
eliminated wherever found. It doesn't matter whether it's
generated by some tool or inserted by the developer.

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

Now you're contradicting yourself. First you say that it's not
about patching to get around stupid libraries, now you say it
is about patching to get around stupid libraries.

John Roth
>
> Daniel Dittmar