2009/7/11 Steven D'Aprano <st...@remove-this-cybersource.com.au>: > So is design-by-contract just another way of saying "let's hope the data > is valid, because if it's not, we're screwed"?
Not at all. Design By Contract is about assigning responsibility for checking. If you don't assign responsibility then a pile of things end up getting checked over and over again, because everybody is assuming responsibility, and some things don't get checked at all because everyone assumes that somebody else is checking. In DbC, the pre-condition on data coming in to a program from outside will usually simply be "true" -- nothing at all is assumed about it. But when you pass it from an input conditioning routine to a processing routine, the input conditioning routine should be able to make guarantees about what it passes, and the processing routine should be able to assume that those guarantees are met without having to check it again (after all, what was the conditioning routine there for?). Assertions might be useful in testing (because they save having to repeat the same set of test cases on absolutely every test run) and they're certainly useful in documenting, but if they're any use at all in the production run-time then there's something wrong with your development and testing processes. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
