Clarity vs. code reuse/generality
digitig at gmail.com
Sat Jul 11 20:33:19 CEST 2009
2009/7/11 Steven D'Aprano <steve at 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.
More information about the Python-list