Reading list: Design by contract, by Example

Originally posted on May 28, 2008.
I used to have a blog, then discontinued. Here, I am reposting some of the old content, the one I still like or and that I feel still somewhat relevant.

Design by contract, by example is a kind of nice book.
I mean, for me, it failed completely to the goal of pushing towards design by contract, and still was very useful: by stressing on immutable classes and some sound design principles guidelines, and by clarifying a language - functions and objects contracts - that is becoming more and more common because of its expressiveness of responsibilities in interfaces.

I bought it because I was interested in software contracts.
Software contracts, as defined by Meyer, are simply an enhanced (and somewhat, object-oriented) version of the pre- and post- conditions used in algorithm analysis since Donald Knuth.
The promise is exceptional: provide bug-free components, able even to avoid bugs like the one that affected the Arianne 5 crash. Not only: it should allow for an always up-to-date documentation, because it would be an effective part of the object interface.

Unfortunately, the book does nothing to sell really this concept. Instead, it makes it quite clear that you have to use the Eiffel language to unleash all the power of software contracts.
Well, sort of.
Dynamic languages allows for several extensions to the language, without the need of preprocessors. It is thus possible to add some DBC, like the Pre-Post-Conditions in the Python decorator Library.
Unfortunately, although not as cumbersome as using a preprocessor, these methods are not exactly a complete DBC implementation; moreover, unit tests offer a similar confidence in the software, while much easier to introduce as a development practice.

That said, I would really recommend the book to anyone willing to improve his design skills.
DBC require a completely different design perspective, focusing on a programming style that, by separating queries by operation stress particularly on avoiding side effects, and on a programming style that can easily allow for parallel processing. If it may seems too abstract, the authors show it in a very concrete way, with a complete set of principles and guidelines, and full examples on how to apply them.

The book is also a very good introduction to a terminology (software contracts) that proves very effective expressing concepts and designs - or to find flaws during a review.
Actually, I have found this second aspect even more compelling than the previous. Once the basic idea of software contract is well-defined, analysis of interfaces, API and designs is definitely easier; and although these are concepts quite a lot in use nowadays, I still think that an operative definition (even by means of techniques and languages not used in the project) helps quite a lot in their usage and communication.

• Design by Contract, by Example
• ISBN: 0201634600
• ISBN-13: 978-0201634600