AOP use cases

[John Roth]

"John J. Lee" <jjl at pobox.com> wrote in message
news:87pta6qnw4.fsf at pobox.com...
> "John Roth" <newsgroups at jhrothjr.com> writes:
> [...]
> > 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.)
>
> That's unfair.
>
> Regardless of your view of its importance, AOP is clearly sufficiently
> well-motivated purely in terms of separation of concerns.  That it's
> also useful as a hack to patch badly-designed software written in
> inflexible languages doesn't change that in the least.

Maybe I should say it a bit clearer then. It still looks like a
hack to me.

One of the reasons I say this is that I work a bit with XP.
A major factor in XP is refactoring, driven by a relentless
search and destroy on any form of duplication. People who
do this pretty much say that they don't usually get into problems
where you have to go in and hack entry points into someone
else's modules.

It's a solution looking for a problem. The only place I can see
it being useful is for things like traces, where you don't want to
recompile the program just to stick in some monitoring, and
for programs that you don't own so that you can't fix the
darn thing.

John Roth
>
>
> John