[aosd-discuss] AW: discuss Digest, Vol 19, Issue 9

[Jonathan Aldrich]

Mira wrote (and Gregor supported):
> 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.

I think there's some truth to both sides here.  AOP *does* make it easier to 
understand and evolve a concern that *crosscuts* an ordinary OO 
decomposition--and it does so even without tool support.

However, without tool support, AOP makes it harder to understand and evolve 
*base* code, for the reason that everyone cites: you can't see which aspects 
apply to it, and so you can't tell what's going on, and if you edit the code 
you might break the aspects.  If you claim, as Gregor did, that AOP *only* 
helps you, even without tools, that's because you're ignoring the base code.

Tool support mitigates this issue, at least in a world where you know all 
the pointcuts that are going to apply to your code--because now you can see 
which aspects apply to code and make sure that you don't break them as you 
evolve the system.  So without tool support, AOP makes it easier to deal 
with crosscutting code but harder to deal with base code.  With tool 
support, AOP makes it easier to deal with crosscutting code and about the 
same (maybe better, maybe worse) for base code.  In this sense, AOP strongly 
depends on good tool support.

If you don't have tool support, AOP can still be a good idea; but that's a 
judgment call which will depend on the situation.  If the improvement in 
modularity for crosscutting code is "greater" than the loss of modularity 
for base code, that would be an argument in favor of aspects.

As Eric Tanter mentioned, I have been working on the theory of a module 
system that can be used to provide a slightly different tradeoff in a 
distributed development setting where you don't know all the aspects that 
apply to your code.  In this solution, you add explicit pointcuts to the 
interface of a module and aspects can only advise those explicit pointcuts, 
or public members of the module.  The tradeoff here is that your reasoning 
about base code within a module is basically unaffected, but as the solution 
is not completely oblivious and as you are restricting aspects, you gain 
only part of the benefit of aspects.

There's no free lunch: either you restrict the aspects with a module system, 
you use tools to show where aspects apply (which may be impossible in the 
distributed development case), or you lose some modular reasoning about base 
code (but still gain modular reasoning about crosscutting concerns, as 
Gregor says).


Aspects vs. Friends
----------------------
The "breaking encapsulation problem" (which is primarily a problem without 
tool support, or in distributed settings where tool support is impossible) 
is different from the "friend" issue that Awais cites in C++.  In C++, you 
can look at a class and see who its friends are, so you know who is 
depending on your code.  With aspects, you don't know who is advising you 
unless you have tool support, so these dependencies are not explicit and are 
therefore more dangerous.

The issue is *not* whether AOP is misused or not.  It is that even good uses 
of AOP can be confusing if someone looking at the base code without tool 
support can't easily see which aspects apply.


On tools in AOP and OOP
-----------------------------
Some of the analogies drawn between AOP and OOP are overly simplistic.

There is a difference between pointcuts in AOP and polymorphic call sites in 
OOP.  In OOP, the call site is explicit, and you can go to the interface of 
the statically bound class and get the specification of what the method is 
supposed to do.  It's true that you need tool support to try to figure out 
which method is *actually* invoked, but most of the time you don't care: 
just reading the specification in the interface or superclass tells you 
enough of what you need to know (hopefully your library author did include a 
specification, at least in javadoc!).  In AOP, the advice is only explicit 
if you have tool support, which is why I would argue that tool support is 
more important for AOP than for OOP.

Just my 2 cents ;-)

Jonathan Aldrich
http://www.cs.cmu.edu/~aldrich/