Hi guys, i have recently been reading a fantastic book on Dbc (Design by Contract by Example by Richard Mitchell and Jim McKim) which has opened my eyes to the value of contract driven programming (pre-conditions, post-conditions and invariants) and am really surprised by the low number of developers who use design by contract principles to create software. The language used to demonstrate problems in the above mentioned book is Eiffel which is not widely used in development but that should not deter you at all just think of it as a specialized language in which it is easy to represent contracts(the object constraint language (OCL) can also be used to represent contracts). Design by contract is a technique that forces u to think harder and more thoroughly about your programs which is always a benefit. It is not easy to learn but with the above mentioned book the slope of learning curve is substantially flattened.

Pls I dnt mind having a copy of that book, sincerely I most time follow the water model to design my software, and that's all. Pls can you send It to me, thanks. Email: oshadami.mj@gmail.com

mj: Pls I dnt mind having a copy of that book, sincerely I most time follow the water model to design my software, and that's all. Pls can you send It to me, thanks. Email: oshadami.mj@gmail.com

The waterfall model is a software process model and Dbc is a software design technique usually applied during component-level design which is a software process workflow so Dbc is process agnostic. Which means u can still follow the waterfall model(adapted to your project off course)and apply Dbc in your design workflow. As for a copy of the book sorry i only have it in hard copy.

In concept, it's one of the trade-offs of Test Driven Development. You write tests before you write code for the feature, this in a way forces you to code to your tests.

farouqzaib: In concept, it's one of the trade-offs of Test Driven Development. You write tests before you write code for the feature, this in a way forces you to code to your tests.

I totally agree but i think contracts tend to deal with more general cases and unit tests(type of test performed during TTD) deal with more specific cases. I strongly believe that contracts help to write more effective tests since it removes the need to add tedious repetitive tests for invalid arguments. Contracts specify the minimum you can expect from the function, whereas unit tests attempt to validate the actual behaviour for a particular set of inputs.

harryobas:

I totally agree but i think contracts tend to deal with more general cases and unit tests(type of test performed during TTD) deal with more specific cases. I strongly believe that contracts help to write more effective tests since it removes the need to add tedious repetitive tests for invalid arguments. Contracts specify the minimum you can expect from the function, whereas unit tests attempt to validate the actual behaviour for a particular set of inputs.

+1!