[aosd-discuss] "AOP considered harmful"

[Ron Bodkin]

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


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