What are the best practices for Design by Contract programming

Question

What are the best practices for Design by Contract programming.

At college I learned the design by contract paradigma (in an OO environment) We've learned three ways to tackle the problem :

1) Total Programming : Covers all possible exceptional cases in its effect (cf. Math)

2) Nominal Programming : Only 'promises' the right effects when the preconditions are met. (otherwise effect is undefined)

3) Defensive Programming : Use exceptions to signal illegal invocations of methods

Now, we have focussed in different OO scenarios on the correct use in each situation, but we haven't learned WHEN to use WHICH... (Mostly the tactics where inforced by the exercice..)

Now I think it's very very strange that I haven't asked my teacher (but then again, during lectures, noone has)

Personally, I never use nominal now, and tend to replace preconditions with exceptions (so i rather use : throws IllegalDivisionByZero, than stating 'precondition : divider should differ from zero) and only program total what makes sense (so I wouldn't return a conventional value on division by zero), but this method is just based on personal findings and likes.

so I am asking you guys :

Are there any best practises??

Answer 1

I didn't know about this division, and it doesn't really reflect my experience.

Total Programming is virtually impossible. You could not guarantee that you cover all exceptional cases. So basically you should limit your scope and reject the situations that are out of scope (that's the role of the Pre-conditions)

Nominal Programming is not desired. Undefined effect should be banned.

Defensive Programming is a must. You should always signal illegal invocations of methods.

I'm in favour of the implementation of the complete Design-by-Contract elements, which is, in my opinions a practical and affortable version of the Total Programming

Preconditions (a kind of Defensive Programming) to signal illegal invocation of the method. Try to limit your scope as much as you can so that you could simplify the code. Avoid complex implementation if possible by narrowing a little bit the scope.

Postconditions to raise an error if the desired effect is not obtained. Even if it your fault, you should notify the caller that you miss your goal.

Invariants to check that the object consistency is preserved.