In other words, if you step back from the job at hand and factor your components more generally, you're likely to arrive at a better design. Although interesting in their own right, the value of some of the implementations presented in Design Patterns and Contracts is also open to question. When the language changes, the whole interpreter needs to be regenerated. I've done just this often in my practice, that is, coded lexical objects that parse themselves. In ObjectRexx, it's a pattern that allows you to write an MC6805 assembler in an evening.
Truth is beauty, beauty truth, even in programming.
There is indeed use in documenting what one anticipates, as long as that effort does not distract programmers from their main task of preparing for the unanticipated. I enjoyed reading this book, even if I spent about half the time wondering at its pretensions. The authors mean well, and their goals and methods excercise the mind strenuously even in refutation.