[aosd-discuss] "AOP considered harmful"

[Gregor Kiczales]

Maximilian Stoerzer said:

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

Mira Mezini said:

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

Eric Tanter said:

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

But don't cast Mira's point aside too quickly.

IMHO, to really understand this question, its critical to consider the SAME
functionality implemented with AOP and not AOP.  While these points have been
made before, its worth it to make them again.

But first...

Let's agree that AOP, like any tool, CAN lead to bade code.

Let's also agree that clearly its easier to use AOP with good tool support
than without. On the other hand, its fairly hard to write a real program
these days without tool support, because you just need help remembering all
the APIs and stuff, and as your program gets larger, you need help remembering
the structure of your own code. So AOP wants tool support, but it isn't alone
in that regard, so do OOP and any XOP, as the program gets to have any size
to it.

I want to note an objection to the claim that type polymorphism is necessarily
easier to grasp in one's head than pointcuts and advice. If you have a truly
polymorphic call site, it can be darn hard to understand under what circumstances
an instance of one class vs. another gets there. That's exactly analogous to dynamic
pointcuts (this, target and args in AspectJ) of course. Static pointcuts don't seem
really harder to grasp than mono-morphic calls.



Now to the main point... that AOP makes programs that should use AOP simpler
to understand, not harder.

The key point, as Mira says, is that if you have a crosscutting concern, that
has any kind of well-defined structure to it, AOP makes that explicit in the code,
and as a result the tool can show it to you. Take even the darn simple display
updating example.

If you code that without AOP, and you want to understand "what is going on" then
all you can do is use grep and try to piece together the structure from all the
individual update calls. You are trying to reconstruct the forest from the trees.

If you use AOP, then you are sitting there looking at something like:

  pointcut change(): ...;

  after() returning: change() && !cflowbelow(change()) { ... }

and the structure (the forest) is already explicit and declarative. Simple tool
support can give you the trees (by annotating each shadow), or other views on
the forest (e.g. the visualizer).  All of that is possible because of the 
declarative description of the structure of the ccc.

IMHO, that's really the key point wrt AOP requiring tooling. 

So if you have an example where the use of AOP is truly warranted, then that
example will be:
 
  - easier to understand with AOP even without tooling
  - and much easier to understand with AOP with tooling

Even the trivial display updating example shows that. More complex examples show
it more clearly. The same is true for other AOP mechanisms like inter-type declarations, 
slices etc.

The key is to be sure to compare apples and apples -- to compare AOP and non-AOP
implementations of examples that warrant the use of AOP.