|
|
Re: Contract-Driven Development
|
Posted: Mar 6, 2004 9:11 PM
|
|
> Perhaps you imply more than the author states ;-)
> Maybe the languages he's now using have little support for
> DbC and good support for TDD?
That's probably the main reason. As far as I can tell, to do DbC right, it needs to be an integral part of the language you're working in ... otherwise, it's really hard to do preconditions on abstract ("deferred") classes and routines, inheritance of preconditions to preserve Liskov substitutablilty, and automatic documentation of preconditions. This means a) the language has DbC from the start (only Eiffel and Sather, AFAIK), b) the language allows metaobject protocols and hygenic macros (e.g. Smalltalk, Lisp, and similar languages), or c) the programmer introduces a preprocessor (e.g. iContract or JContract for JUnit).
Implementing DbC with macros, metaobject protocols, or preprocessors is probably a lot of work. Aspects may be easier, although I've never liked the idea of contracts in a separate file from the methods they describe; there's too much opportunity for obsolete contracts, and enough context-switching to discourage people from writing contracts unless they have to.
OTOH, unit testing is almost trivial to implement, and covers enough of the same territory. What unit testing lacks is the ability to trap and diagnose problems during acceptance tests and production operation. (Also, implementing "abstract tests" for arbitrary descendants is a real pain, and unit-testing doesn't have the auto-documentation ability of DbC.)
|
|
Previous Topic
