 |
|
Design Patterns and Contracts, by Jean-Marc Jiziquel, Michel Train, and Christine Mingins, is a software engineering text about enhancing the usefulness of the design patterns by applying Design by Contract, a process of "spelling out unambiguously" the mutual obligations of objects. Although some of the authors' speculations seem epistemologically flawed as well as gassily expressed, the book is full of working Eiffel implementations of canonical design patterns. It should, therefore, be interesting for the object designer.
Design Patterns and Contracts is concerned, in classic computer-science fashion, with correctness. Design Patterns and Contracts expresses the thought that "Design by Contract prompts developers to specify precisely every consistency condition that could go wrong and to assign explicitly the responsibility of it to either the routine caller (the client) or the routine implementation (the contractor)." Perhaps words like "precisely every" should be measured out sparingly when describing the computing cosmos, which encompasses improbability fields large enough to swallow an Arianne space rocket.
Design Patterns and Contracts is a hard read. Its prose style is Ivory Tower Deluxe, and then some:
Taking an extreme position, we could consider the whole system as a set of nodes taking part in collaborations whose composition yields the system behavior.
This is not an extreme position. This is the position the linker takes when it links your code. But wait, it gets deeper:
The next step stems from this foundation to build what will provide the real added value of the phase. The second step is to identify collaborations between items. From a naive translation, we obtain lots of concepts with lots of specific collaborations. This is where the real work begins. Going from one phase to another, as we stated before, we observe a semantics shift. Namely, we move from application semantics to operational semantics. With that idea in mind, we observe that many applicative semantics notions obey the same operational model: they are used in the same way and respond to the same protocol. Most of the time, this is the place where flexibility and evolutive concerns arise. Collaborations have to be abstract at the operational level. Then, patterns can be perceived. Abstraction from detailed application semantics is the key step toward good design and the identification of the proper patterns.
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. True, if not original, and could you get to the point a little faster, please? You end up wishing the authors would dispense with terms like "applicative semantics notions" and just spit out the words "fragments of application code". Most would also choose "remembering to consider maintenance and code re-use" over "flexibility and evolutive concerns" anytime, on the theory that the purpose of writing is to communicate.
Although interesting in their own right, the value of some of the implementations presented in Design Patterns and Contracts is also open to question. Regarding the Interpreter (GoF 243) pattern, the authors ask rhetorically:
When dealing with simple languages, it is common to look for an alternative to a table-driven-generated parser in which semantic interpretation is hard-coded into rules. When the language changes, the whole interpreter needs to be regenerated. Why not try a simple object-oriented approach whereby each notion gets mapped to a class?
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. But the four pages that follow present an unaesthetic, if nominally correct, piece of code to parse one boolean expression, code both immeasurably less elegant than minimalist parsers a la FORTH or yacc and algorithmically as muddy as the Mississippi when compared to similar efforts executed in logic programming style. 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. Design Patterns and Contracts whips the latent tendentiousness in software engineering methodology up to new heights of froth, yet remains entertaining both in offhand fashion as an unintentional parody of its genre, and sincerely as a collection of genuinely interesting Eiffel riffs (downloadable from http://www.irisa.fr/prive/jezequel/DesignPatterns) on common design patterns. 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.
-- Jack J. Woehr (http://www.well.com/~jax/rcfb)
|
Explanation of ERCB rating scale:
|
