What are the best practices for Design by Contract programming.

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??

From stackoverflow

• It all boils down to what responsibilities do you wish to assign to the client and the implementer of the contract.

  In defensive programming you force the implementer to check for error conditions which can be costy or even impossible in some cases. Imagine a contract specified by the binarySearch for example your input array has to be sorted. you can't detect this while running the algorithm. you have to do a manual check for it which will actually bump the execution time an order of magnitude. to back my opinion up is the signature of the method from the javadocs.

  Another point is People and frameworks now tend to implement exception translation mechanisms which is used mainly to translate checked exceptions (defensive style) to runtime exceptions that will just pop up if something wrong happens. this way the client and implementer of the contract has less to worry about while dealing with each other.

  Again this is my personal opinion backed only with what limited experience I have, I'd love to hear more about this subject.

  Mykola Golubyev : You can check either array is sorted as precondition. We do this in the c++ with asserts.

  MahdeTo : checking the whole array is sorted takes more time than actually doing a binary search in it :)

  Peter : Just some thoughts : you could check preconditions only in certain modes, say for unittesting no? Further a precondition can be just stated and not tested, of course

• ...but we haven't learned WHEN to use WHICH...

  I think the best practice is to be "as defensive as possible". Do your runtime checks if you can. As @MahdeTo has mentioned sometimes that's impossible for performance reasons; in such cases fall back on undefined or unsatisfactory behavior.

  That said, be explicit in your documentation as to what has runtime checks and what does not.

• Like much of computing "it depends" is probably the best answer.

  Design by contract/programming by contract can help development greatly by explicitly documenting the conditions for a function. Just the documentation can be a help without even making it into (compiled) code.

  Where feasible I recommend defensive - checking every condition. BUT only for development and debug builds. In this way most invalid assumptions are caught when the conditions are broken. A good build system would allow you to turn the different condition types on and off at a module or file level - as well as globally.

  The actions taken in release versions of software then depend upon the system and how the condition is triggered ( usual distinction between external and internal interfaces ). The release version could be 'total programming' - all conditions give a defined result (which can include errors or NaN)

  To me "nominal programming" is a dead end in the real world. You assume that if you passed the right values in (which of course you did) then the value you receive is good. If your assumption was wrong - you break down.

• I think that test driven programming is the answer. Before actually implementing the module, you first create a unit test (call it a contract). Then gradually implement the functionality and make sure the contract is still valid as you go. Usually I start with plain stubs and mockups, then gradually fill out the rest replacing the stabs with real stuff. Keep improving and making the test stronger. At the end you end up with a robust implementation of said module plus you've got a fantastic test bed - coded implementation of the contract. Later on, if someone modifies the module, first you see if it can still fit the test bed. If it doesn't, the contract is broken - reject the changes. Or, the contract is outdated, - fix the unit tests. And so on.. Boring cycle of software development :)

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