On software quality and engineering

[Doug.Palmer at csiro.au]

> supports Design-By-Contract in Java (DBC was one of the foundation 
> techniques behind Bertrand Meyer's "Eiffel" language, IIRC):

You do remember correctly. His book, "Object-Oriented Software Construction"
is largely built around it. Although I think that Eiffel makes a bit of a
meal of it.

>    http://www.reliable-systems.com/tools/iContract/iContract.htm

Neato. I also notice that iContract can be integrated into AspectJ[*]. This
is interesting because once you start weaving a program out of aspects, I
think a declaration of what a function is supposed to do becomes important.
Both to ensure that your aspects haven't broken the contract and to allow
secure dynamic addition and removal of aspects.

However, it seems to me that DBC will only really be useful when you can
reason about the pre- and post-conditions and invariants. So that you can
detect potential contract violations statically. And so that you can remove
redundant checks. I couldn't figure out whether iContract does this --
beyond removing redundant invariant checks.

[*] A quick intro to Aspect-Oriented Programming (AOP), for those who
haven't heard of it. AOP goes one further than object-oriented programming
splits up functionality into "aspects" cross-cutting concerns that need not
be present in all programs. For example, you might or might not want a
change to an object to trigger a notification to dependents, or be wrapped
in a transaction, or be permission checked. With AOP, you choose the core
function and then add "aspects" (notifications, transactions, security,
functional extensions, ...) to the function. The result is then "woven" into
a program. 

I think that this would be a cool thing to do dynamically, so that software
components can form ad-hoc transactional groupings and such-like. But to do
this, you need a mechanism to ensure that the core functionality of the
component isn't broken by hostile aspects. Hence DBC.