Talk:Design by contract

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Design by contract article.
Article policies

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

Contents

[edit] 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. --P3d0 20:24, Jan 31, 2005 (UTC)

[edit] 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. --P3d0 16:46, 2 Sep 2004 (UTC)

[edit] 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. --P3d0 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 Feb 2005 (UTC)

[edit] 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, 2005 Feb 9 (UTC)


[edit] Time/Space Contracts

Somebody added something here on time/space contracts. If the person who edited that article this way sees this (or someone else who knows), could he/she tell me where information can be found on that? Thanks! Wouter Lievens 15:35, 28 May 2005 (UTC)

[edit] "Fail Hard"

Using the DBC methodology, the program code itself must never try to verify the contract conditions; the whole idea is that code should "fail hard", with the contract verification being the safety net. (This stands in stark contrast to the defensive programming methodology.) DBC's "fail hard" property makes debugging for-contract behavior much easier because the intended behaviour of each routine is clearly specified.

As a DBC newbie, I didn't understand much of this paragraph, and I don't know what "fail hard" means. A couple of minutes Googling didn't turn up anything relevant. Can someone define this term, and clarify this paragraph a bit? Axlrosen 19:15, 6 November 2005 (UTC)

It's not jargon; it mean just what it says: when a program fails, it should "fail hard" rather than trying to continue to run. As the article says, this concept is a bit controvercial. (I for one heartily endorse it during all phases of development except perhaps final deployment.) --P3d0 22:21, 6 November 2005 (UTC)

[edit] "Obliged" versus "obligated"

The words "obliged" and "obligated" have exactly the same meaning, so I'm inclined to agree with User:Rich_Farmbrough and use the simpler of the two. I disagree with User:SimonP's revert, and I'll re-revert unless anyone has an objection. --P3d0 13:46, 14 February 2006 (UTC)

There two words can actually have a different meaning. Consider these sentences:
He was obliged to her because of her actions
He was obligated to her because of her actions
Also obligated is North American English, while obliged is British, so this would fall under our rule of using the spelling of the original author. - SimonP 16:02, 14 February 2006 (UTC)
There is no clear cut distinction. OED agrees that legal requirement is included in "oblige" (as opposed to obligate), in its lengthy articles. More accessibly the American Heritage Dictionary says " To constrain by physical, legal, social, or moral means." Mirrim Webster has "to constrain by physical, moral, or legal force or by the exigencies of circumstance".
Furthermore Websters 1828 made the reverse distinction, saying of "Obligate" "Until recently, the sense of this word has been restricted to positive and personal acts; and when moral duty or law binds a person to do something, the word oblige has been used. But this distinction is not now observed."
Both words have been in use in the UK for some considerable time.
There are of course cicumstances where "obligate" is to be preferred, in direct quotes and in the technical senses of the word from finance and more importantly biology.
Rich Farmbrough. 16:24, 21 February 2006 (UTC)

[edit] DBC contrasted to defensive programming?

The article currently says:

Using the DBC methodology, the program code itself must never try to verify the contract conditions; the whole idea is that code should "fail hard", with the contract verification being the safety net. (This stands in stark contrast to the defensive programming methodology.)

I believe this to be somewhat incorrect - while a "defensive programmer" may attempt to recover from contract (developer) errors, such as incorrect arguments, it needn't to, as far as I understand what defensive programming is about. In the case of DBC, runtime errors (e.g., network failures, hardware failures, privilege violations) still occur, and are part of the contract. Defensive programming still applies in the sense that these well-defined errors should always be handled. -- intgr 17:06, 24 November 2006 (UTC)

In defensive programming, the callee checks for errors. In DbC, the callee is allowed to assume that the caller has made no errors. I'm not sure what this has to do with network failures etc. --P3d0 17:38, 24 November 2006 (UTC)
Runtime errors like network failures, that would be part of the contract, are covered by "defensive programming". This means that the two approaches generally also work together – the client programmer will have to check for runtime errors defined by the contract. -- intgr 17:58, 24 November 2006 (UTC)
Network conditions can't appear in contracts. A program making assertions about entities outside its control is incorrect according to DBC. So I still don't see your point. --P3d0 17:56, 15 December 2006 (UTC)
Sorry, I am not following you. Do you mean that a program designed with design by contract, that does network operations, assumes that the network never fails? And if the network does fail, the program responds by "failing hard", e.g., segfaulting, as the contract was violated? I'm sure you agree with me that this would be ludicrous.
My view of network failures (for example) map to design by contract, is that the contract precisely defines how each object interacts in case of a network failure. Code using the network backend objects will check for these defined error conditions and act accordingly. This means that all anticipated error conditions are handled, and thus also qualifies as defensive programming.
Please explain what am I missing. -- intgr 18:10, 15 December 2006 (UTC)
Ah I think I see what you mean. I had it backward. Yes, contracts would describe the network failure modes. I guess in that sense a DBC program would be indistinguishable from one using defensive programming. The difference appears when a defensive program checks error conditions caused by other parts of the same software system. DBC doesn't do that. --P3d0 21:54, 15 December 2006 (UTC)
I use both defensive programming and DBC in the same projects. The "defensive" portion is usually the interface to a less reliable part of code -- especially, the public API of a library, or third party code (especially Microsoft authored code). I don't think defensive programming should be considered an alternative or contrasting with DBC in any way, as they work well together. The "defensive" areas of code have a less strict contract, but some contract is always present. —Preceding unsigned comment added by Frank Hileman (talk • contribs) 16:35, 7 March 2008 (UTC)

[edit] Verbosity

Yikes, this is an awfully verbose description of a fairly simple concept. Can it be tightened up so it reads more like an encyclopedia and less like a remedial software engineering text? --P3d0 21:24, 4 January 2007 (UTC)

[edit] Java Comparisons

Why is this being compared with Java (see: "compare to type bounds for Java 5 generics")? Isn't this a more or less language-neutral article? So why does it even need to be mentioned? It's not like Java 5 generics' type bounds are so common that everyone knows what they are. Just my opinion, could be I'm totally off the wall here. -- 156.34.80.248

Agreed; removing per WP:BB. -- intgr 10:32, 2 April 2007 (UTC)

[edit] Languages section

The "Languages implementing DBC" section currently pretty much only consists of a list of DBC implementations and links to their home pages; I think it takes up much more space than worth, and that Wikipedia articles should not contain inline external links unless they're sources. Would anyone oppose to turning it into a simple bulleted list of languages and stripping the external links? -- intgr 06:05, 5 April 2007 (UTC)

I can't found SpringContract in the spring documentation, while it's possible use AOP Infrastructure in Spring to implements contract, there isn't a specific sub-component for this purpose.

[edit] Who owns the trademark?

This article says that Eiffel Software owns the "Design By Contract" unregistered trademark. However, the web page at the Eiffel website says that "Interactive Software Engineering" owns the trademark.

I would like to site the proper owner of the unregistered trademark, but there is some discrepancy.

199.46.245.232 (talk) 01:46, 23 February 2008 (UTC)


The US Patent and Trademark Office lists "Design by Contract" as a Registered Trademark of "Interactive Software Engineering, Inc.".

199.46.245.232 (talk) 06:08, 23 February 2008 (UTC)