[aosd-discuss] "AOP considered harmful"

Wed Apr 27 23:54:06 EST 2005

Ron,

Interesting thoughts. I agree that DbC doesn't say everything there is 
to say about aspect-object interaction.

A traditional "Design by Contractor" ;^) would be shocked by the 
suggestion that aspects might be used to change program behavior in ways 
that might break the contract. However, the examples you mention still 
fit the model, with appropriate considerations.

Your examples roughly fit two categories, exceptional conditions that 
fall outside the "normal state machine" of the system (e.g., a security 
aspect causes premature termination of an activity due to insufficient 
privileges) and logic changes (e.g., changing a pricing algorithm for a 
store).

You make an excellent point that it's fruitful to consider exceptional 
circumstances as somewhat orthogonal to the normal control flow and 
contracts. Following the HyperSpaces approach, I like to picture this 
using a 2D graph to represent the normal state machine and the 3D 
dimension as the location for exceptional states and transitions. There 
are well defined transitions points out of the 2D flow and possibly back 
into it (after recovery).  Hence, as you say, the contracts and state 
machine for exceptional cases are crosscutting to the normal cases. They 
are separable, but interact in nontrivial ways. Why not define the 
corresponding contracts separately, too?

In my judgment, the logic-change category of aspects should force you to 
refine the contracts of your advised modules to allow "reasonable" 
variations through aspects. ("Reasonable" meaning that too much 
flexibility leads to a complex, problematic design.) Inevitably, you'll 
find cases where the contracts aren't flexible enough to accommodate new 
requirements. Refactoring will be required. Robert Martin talks about 
this situation (from a non-AOP perspective) in his book Agile Software 
Development, which I reference extensively in my paper below.

As a straw man proposal, I suggest that there should never be a case 
where aspects are used in ways that violate the contracts of the advised 
modules. If it appears to be necessary, then the underlying modules and 
their contracts need refactoring so that the proposed aspect weaving can 
proceed without contract violation. Forcing a violation, in order to 
maintain "obliviousness", is actually a "design smell". It should only 
be done as a last resort (e.g., you can't refactor a 3rd-party module).

I see all this as further evidence that nontrivial aspect-object 
composition requires aspect-aware design of the modules that may be 
advised. That is, the designers keep module contracts minimal and 
flexible, to accomodate a range of potential advice, yet sufficiently 
concrete to be effective. (You don't want them to be so vague that they 
have no power.) Pure /obliviousness/ usually only works for aspects with 
orthogonal state (e.g., tracing). However, good, aspect-aware designs 
can accomodate weaving /noninvasively/, as long as contracts are 
preserved.

dean

Ron Bodkin wrote:
> In general, I think that respecting existing OO DBC rules is necessary, but
> not sufficient to define how aspects interact with objects. 
> 
> One problem area I've seen related to exceptions (assuming you think the set
> of possible exceptions thrown should be a post condition): I generally think
> exceptions are crosscutting and that you should NOT have to aggregate any
> possible exception that an implementation class might raise into the
> interface of a component. At the least aspect exceptions should be unchecked
> so as to not tangle other components with possible errors in an aspect.  A
> classic example of this is security exception.
> 
> Also, Therapon Skotiniotis and David Lorenz at NorthEastern have written
> interesting papers on the topic (see
> http://www.ccs.neu.edu/home/skotthe/mypapers.html). One discusses where you
> wold want to check invariants before an aspect acts (e.g., think of
> caller-side aspect changing the result for a context) or have the aspect
> ensure the invariant applies (callee-side). 
> 
> In general, traditional OO DBC seems incorrect is if an aspect as an
> external component needs to change the normal behavior. For example,
> consider an aspect that applies a discount, or blocks transactions on a
> suspended account. It's unlikely that the original postconditions of
> calculating price or using an account or a service would reflect the
> additional behavior.
> 
> Indeed, I oppose "weaving" the effects of aspects into the postconditions of
> operations where they apply. Instead, I think we need a DBC concept that
> preserves the modularity of aspects and classes.
> 
> Re: invariants, to me the traditional DBC concepts are just a special case
> of pre-conditions and post-conditions on join points, that could better be
> specified with pointcuts...

Yes, aspects do this very well; I started Contract4J (contract4j.org) to 
use AspectJ for contract enforcement in Java code. It's a natural (and 
oblivious ;) application of AOP.

dean

> 
> 
> -----Original Message-----
> From: Awais Rashid [mailto:marash at comp.lancs.ac.uk] 
> Sent: Wednesday, April 27, 2005 6:42 PM
> To: 'Dean Wampler'; 'Ron Bodkin'
> Cc: 'AOSD'
> Subject: RE: [aosd-discuss] "AOP considered harmful"
> 
> Dean,
> 
> Interesting point indeed. We are exploring similar ideas. You might be
> interested in the following technical report. It discusses the notions of
> dependency alignment, weak and strong orthogonality:
> 
> http://www.comp.lancs.ac.uk/computing/aose/papers/COMP-001-2004.pdf
> 
> Awais.
> 
> 
>>-----Original Message-----
>>From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On 
>>Behalf Of Dean Wampler
>>Sent: 28 April 2005 01:57
>>To: Ron Bodkin
>>Cc: 'AOSD'
>>Subject: Re: [aosd-discuss] "AOP considered harmful"
>>
>>I've given some thought to applying Meyer's "Design by Contract" (DbC) 
>>to aspects and how aspects need to respect the contract of the advised 
>>code.
>>
>>The Liskov Substitution Principal applies; If a class is substitutable 
>>for an interface, then the class+advice must be, too. This means that 
>>if a method in the class stipulates precondition A (conditions that 
>>must be met on entry to the function) and satisfies postcondition B 
>>(guaranteed results, if the preconditions are satisfied) and invariant 
>>C, then before advice needs to be contravariant with respect to A, 
>>convariant with respect to B, and invariant with respect to C.
>>
>>"Contravariant with respect to A" means that the advice must stipulate 
>>a contract equivalent to A or /weaker/ than A; if it stipulated a 
>>contract /stronger/ than A, then it won't be substitutable for the 
>>class. A weaker contract is okay.
>>
>>"Convariant with respect to B" means that it must guarantee to meet 
>>the postconditions B or /stronger/ conditions (again, to satisfy 
>>substitutability, it can't relax the "promise").
>>
>>Finally, any invariants must be respected.
>>
>>I've been working on a paper, which needs a lot of work, that 
>>discusses DbC in more detail (along with other design principles):
>>
>>http://www.aspectprogramming.com/papers/AOPerspectiveOnOOD.pdf
>>
>>dean
>>
>>
>>Ron Bodkin wrote:
>>
>>>[snip]
>>>
>>>Re: the Liskov Substitution Principal and adherence to contracts, I
>>
>>think
>>
>>>most real systems have best efforts informal documentation of 
>>>semantics, which is far less than a contract. So what does it really 
>>>mean that you
>>
>>can
>>
>>>substitute one subtype for another? How do you know what 
>>>pre-conditions
>>
>>and
>>
>>>post-conditions apply?
>>>
>>>[snip]
>>>
>>>-----Original Message-----
>>>From: Juri Memmert [mailto:memmert at jpmdesign.de]
>>>Sent: Tuesday, April 26, 2005 10:20 PM
>>>To: Bill Burke
>>>Cc: AOSD; Ron Bodkin
>>>Subject: Re: [aosd-discuss] "AOP considered harmful"
>>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>Bill Burke wrote:
>>>
>>>[snip]
>>>
>>>
>>>>>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.
>>>
>>>
>>>Yes and no. Unless you messed up your implementation, the Liskov 
>>>Substitution Principle still has to apply. And so you have a general
>>
>>notion
>>
>>>of the contracts the application will abide by. If you did break 
>>>that principle, you've already doomed your application to die a slow 
>>>and agonizing death.
>>>
>>>[snip]  ...
>>
>>--
>>Dean Wampler, Ph.D.
>>dean at aspectprogramming.com
>>http://www.aspectprogramming.com
>>http://www.contract4j.org
>>I want my tombstone to say:
>>    Unknown Application Error in Dean Wampler.exe.
>>    Application Terminated.
>>    [Okay]    [Cancel]
>>
>>__________________________________________________
>>AOSD Discuss mailing list    -    discuss at aosd.net
>>To unsubscribe go to http://aosd.net
> 
> 
> 

-- 
Dean Wampler, Ph.D.
dean at aspectprogramming.com
http://www.aspectprogramming.com
http://www.contract4j.org
I want my tombstone to say:
    Unknown Application Error in Dean Wampler.exe.
    Application Terminated.
    [Okay]    [Cancel]