Talk:Design by contract

Opening heading

Ada needs to be added to the list of langs. Im suprised it is not there in a dbc article!

---

The two versions of this article need merging.

---

The executability of contracts is more a feature of "Programming By Contract". DBC is about software design, and so the executability of the contracts is not really relevant, and it's certainly not the primary way in which DBC is novel. Also, the difference between contracts and assertions is not merely a matter of "depth". The big deal with DBC is that the whole design of the system is based on the contracts, whereas C assertions are just sprinkled around in a rather ad-hoc manner and don't necessarily affect the system's design. Doradus — Preceding undated comment added 07:00, 25 July 2003‎ (UTC)

DBC failure causing hard failures.

Its not a DBC issue that is the concern.

If any program has an error and fails it is a problem.

However, if a program has an error and continues on blindly, that is some circumstances even worse.

The assumption of those anti-dbc is that if our program accepts faults blindly, and carries on, then less harm will happen compared to the program failing. This assumption is false because it implies some analysis of the problem, which clearly hasn't happened because of the exception.

eg. A square root function is called with a negative number. The system fails. The called function cannot determine what to do, since it doesn't know its context. The only way to make a decision as to what to do is more analysis.

If you are careful, you can put in place a top level error handler that does something sensible. This is for DBC or non DBC.

The non DBC solution would be return something, anything, and hope everthing works.

There is a middle ground. If there's some way to tell what objects have probably been corrupted, then that subsystem could be shut down somewhat cleanly, and perhaps even re-initialized. For instance, if you're talking about a database interface, then each transaction could be wrapped with an exception handler that rolls back the transaction, cleans up some data structures, and reports an error in the appropriate manner. The functionality that led to the exception could be disabled until an admin re-enables it. And so on. --Doradus 20:24, 31 January 2005 (UTC)

Assertions not strong enough

Let's stick to the Sqrt(-1) idea. Suppose we have a Math class that has a Sqrt function, defined in pre/post conditions:

pre: x >= 0
post: Sqr(result) == x

This looks like a good contract. Now a smart person inherits the Math class, and derives a ComplexMath class, which can handle complex numbers in addition to real numbers. The Sqrt function would look like:

pre:
post: Sqr(result) == x

So now we have a weaker precondition and a stronger postcondition. Nothing surprising, but suppose we have some code that says:

Math math = new ComplexMath();
i = math.Sqrt(-1);

Now what should this do - should it compile, run, crash or what? Any implementation using assertions would simply call ComplexMath.Sqrt() and return a complex number. But that is not the contract the client intended to use. This code should should not be allowed to pass any Q.A. test, because the programmer expected Math behaviour and not ComplexMath. There's no telling what will happen if the next part of the program gets the complex result.

So because the client uses the Math contract (interface) here by declaring math as Math, the preconditions and postconditions of Math should apply too.

That is a good observation. Clearly, I agree with you. There's an extensive Usenet thread on the topic. (Look especially at article 74 which, I think, sums up the concensus that we all reached in that thread.) (Links removed because they triggered Wikipedia's stupid spam filter; see old version.)

I'm not sure how (or even if) it should be incorporated into the article though. --Doradus 16:46, 2 September 2004 (UTC)

Static Typing

In my book (figure of speech), static typing is a way of enforcing preconditions for a function at compile time, because it enforces the need that (for instance) the parameter x is always an integer. Do other agree with this view?

I agree, for whatever that's worth. That's exactly why covariant parameter redefinition is controversial: it's equivalent to strengthening a precondition. --Doradus 20:16, Jan 31, 2005 (UTC)

Shure it is. And static typing can be used for invariants as well - for example with ranges. So I wonder if languages like with powerfull static typing (i.E. Ada) should be considered DOC as well. -- Krischik 07:02, 1 February 2005 (UTC)

References

I'm interested in this topic but the article seems a bit cursory. Would someone mind putting up a few references to guide my research? - Drewish 21:22, 2005 Feb 6 (UTC)

we can't do anything you can't do as well. Google for "Design by contract" and add pages of interest. But apart from that you are right. --Krischik 06:28, 8 Feb 2005 (UTC)

While I agree with you in principle, I'm certain that there are contributors who could provide the titles of a few of the definitive papers on the topic. Besides it's the wikipedia way, as it says at the bottom of every edit page, "Please cite your sources so others can check your work." Drewish 20:58, 9 February 2005 (UTC)