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

[Maximilian Stoerzer]

Hi Jonathan,

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

Thanks for that mail, that is exactly the point I wanted to make when 
saying AOP depends on tool support.

I completely agree that CCC can be considerably clearer expressed in an 
aspect, and that this even promotes understandability of the base code 
where the tangeled concern has been removed.

However, I think as soon as the CCC code mingles with the semantics of 
the base code (i.e. they are not independent of each other) as a 
programmer you have to know what is going on - i.e. you have to be aware 
of the aspect. Otherwise you will not understand semantics of the woven 
system. Therefore you need tools.

I think this is especially important when considering system evolution. 
When the base code evolves, this can easily break affecting aspects if 
the programmer is not aware of then.

Best regards,
	Max

Jonathan Aldrich wrote:
> 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.
> 

> 
> 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/
> 
> 
> __________________________________________________
> AOSD Discuss mailing list    -    discuss at aosd.net
> To unsubscribe go to http://aosd.net

-- 
Maximilian Stoerzer
Lehrstuhl Software Systeme - FMI - University of Passau
Tel: +49 851 509 3096, eMail: stoerzer at fmi.uni-passau.de