[aosd-discuss] "AOP considered harmful"

Ron Bodkin rbodkin at newaspects.com
Mon Apr 25 12:47:42 EST 2005


First off, I'd say that the best tool for understanding a system as a whole
is a good design. AOP improves the modularity and supports traceable
implementations, making it easier to understand without tools support. An
overly complicated OO system can be effectively impossible to reason about,
too.

I question this in practice in large OO systems. Without tools support,
finding the possible subclasses or implementers of something is quite
difficult, so knowing what actual implementation code will execute is hard.
The idea of "looking at your code" breaks down on the kind of real (large)
systems where modularity most matters. Of course for systems that might be
extended by 3rd parties, it's not possible if you don't have their
extensions.

And of course, identifying the possible implementations that might get
assigned to a given field can require reading all the code (possibly
including XML configuration files). In the case of worker objects like
Runnable or Action, in practice you often can't reasonably figure out what
will execute by static analysis either.

Re: the question of dynamic parts to pointcuts, that to me is analogous to
the fact that in general one knows which branches of an if test might
potentially execute. 

Indeed, having good tools to see dynamic behavior is often a requirement to
understand real code. A good debugger is helpful for this, and, in fact, AOP
makes it easier to trace code (even incomprehensible pure OO code) to
understand what's happening.

I'd also note that, in practice, large project use all kinds of special-case
obscure artifacts to address crosscutting, that are also hard to follow
without tools support, but (to my knowledge), don't offer good tools support
either, e.g.,

- dynamic proxies (either created by the JDK or using bytecode libraries
like ASM)
- code generators like Xdoclet (sure you can read the _generated_ code, but
how do you trace it back to the sources?)
- execution "containers" (e.g., Servlet and EJB)

You might argue that these aren't OO, but any real critique of AOP needs to
address the shortcomings that motivated such alternatives.


-----Original Message-----
From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On Behalf
Of Eric Tanter
Sent: Monday, April 25, 2005 10:11 AM
To: Mira Mezini
Cc: discuss at aosd.net
Subject: Re: [aosd-discuss] "AOP considered harmful"

>> as one of the authors of the referenced paper, just a short note: This
>> paper was written for a panel discussion, and indeed intended to be
>> provocative.
>>
>> However, I think that AOP as we see it now can result in reduced 
>> program
>> understandability, if used in the wrong way. Additionally AOP imho
>> strongly depends on tool support (thanks for ajdt, great tool in that
>> context!).
>
> I disagree with the above. AOP makes great tool support like ajdt 
> *possible*
> rather than "strongly depending on them"! Pointcuts make the 
> crosscutting
> structure, which implicitly exists anyway in an OO equivalent, 
> explicit and
> hence displayable by a "stupid" tool. By this, it actually improves 
> overall
> program understanding rather than reducing it, IMHO.

But what Max said -which I believe is true- is that without tool 
support, you cannot determine what is going to happen at execution just 
by looking at your code unless you're good enough to 'expand' 
predicates in your mind at any time. Type polymorphism in OOP is 
arguably much easier to grasp in one's head that pointcut shadows.
So yes, good tools support is even more necessary for AOP I guess. And 
still, another point that is made in the paper is that even with tool 
support, if your pointcuts have dynamic parts, you can only know what 
aspects 'potentially' apply.

-- Eric


__________________________________________________
AOSD Discuss mailing list    -    discuss at aosd.net
To unsubscribe go to http://aosd.net






More information about the discuss mailing list