[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
design by contract
Oyvind Teig says:
>After discussing this, I read an article on Eiffel:
> "Building bug-free O-O software:
> An introduction to Design by Contract"
>This states that:
> Under the Design by Contract theory, a software system is viewed as
>a set of communicating components whose interaction is based on
>precisely defined specifications of the mutual obligations --
I haven't yet had time to download the refs. But it sounds like a
perfectly good umbrella describing both procedures and occam processes.
Unfortunately it doesn't exactly forbid side effects (which can be
considered part of the "contract" too if the contract is a lawyerly
1,000 pages long).
> Concurrency and distribution: the principles of Design by Contract
>yield a fascinating solution, described elsewhere in these Web pages,
>to the problem of concurrent and distribution object-oriented
>programming (avoiding the so-called "inheritance anomaly" and other
>non-issues of O-O concurrent computation, resulting from a
>misunderstanding of object technology).
O ho! I feel a "brief for the defense" here. I don't think there's any
misunderstanding. Every OO reference I've ever seen has bragged about
inheritance (and polymorphism) as essential advantages of OO. Now that
they turn out to be a drag, we are to redefine them as "non-issues"?
>What do you say about this? Does it make OO "better"?
>Also, this language seems to be built much on assertions. Is
>this something for (an new) occam?
Those who've dug deeper can answer fairer... but my basic criterion
remains. Does it eliminate knowledge entanglement? Will the contracting
entities work together as black boxes based on knowledge ONLY of a
SHORT contract description with NO hidden global or system assumptions?
No massive implied object definitions, for example?
Key test: can you hook them up and get them running in a new system
configuration in an hour, with no knowledge but the contract?