[aosd-discuss] "AOP considered harmful"

[Juri Memmert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dean Wampler wrote:

Dean,

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

this is an interesting idea in that it would require revisiting existing
contracts to accommodate for an aspect.
I do approach the issue a bit differently in that I declare a new
contract to replace the old contract in the presence of an aspect that
requires a change to the original contract.

This, in my experience has a few neat properties...

Assume you have a contract governing the calculation of pricing for a
store. Different parts of the contract apply to n places in the code,
For instance, the pricing calculation defines that there will be rebates
for any item in the store with more than x items in stock.
It also defines that frequent customers will also get n% off the price.
So you could end up with a contract defining that the calculation
component requires the # of items in stock and the customer's status
(frequent or not) and would put out a price between the nominal price of
the item and n% less.
This contract requires at least 2 components to be present to work.

So the concern model for the contract states

Component1 admits (50% weight) Contract1
Component2 admits (50% weight) Contract1

This means that unless there is a Component1 and a Component 2, there
can be no contract because if one were missing, the weight of the
relationship would drop below 100%.

If you now change that contract to a different one, you could do this in
two ways:

Component1 admits Contract2
Component2 admits Contract2

or

Component1 admits Contract1
Component2 admits Contract1
Contract2 overrides Contract1

The latter form has one advantage. It allows the following construct:

Component1 admits Contract1
Component2 admits Contract1
Contract2 overrides Contract1
Contract3 overrides Contract1

requires that Contract2 and Contract3 are connected by a relationship to
ascertain that they do not introduce incompatible constraints.
So in the end, you end up with something like this:

Component1 admits Contract1
Component2 admits Contract1
UnionOfContract2AndContract3 logically_implements Contract2
UnionOfContract2AndContract3 logically_implements Contract3
UnionOfContract2AndContract3 overrides Contract1

That way, all artifacts created in the contract refinement process are
present in the concern model, you know which ones to change or remove, etc.


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

A agree that obliviousness is a problematic issue when dealing with
contracts... but, in some degree, it depends on whether you consider the
contract to be part of the application logic or not.
There are contracts that are merely part of the application code, to
handle some code-only construct and property.
Other contracts are the implementation of a business case or another
conceptual entity. They do, of course, have a physical implementation,
but they are not much different from other conceptual entities.
And those, you can treat quite well on the concern level, discussing how
they interact, evolve, etc. This doesn't remove the need to  treat them
in code, but it gives dealing with them a different focus.


	Juri


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCcO7EdlXiXRccbPMRAjnDAJ0cTUreDRbf0x+vLpN4AtUJcGr0gACgsB0L
tdkqKCV9XinR/JxjfX/Z5uQ=
=mAwA
-----END PGP SIGNATURE-----