Jean-Marc Jézéquel
Michel Train 
Christine Mingins

Addison-Wesley, 1999
ISBN 0201309599
368 pages 1 edition 
October 15, 1999


The idea of systematically identifying and documenting design patterns as autonomous entities was born in the late 80's. It was brought into the mainstream by such people as Beck, Ward, Coplien, Booch, Kerth, Johnson, etc. (known as the Hillside Group). However the main event in this emerging field was the publication, in 1995, of the book Design Patterns: Elements of Reusable Object Oriented Software by the so-called Gang of Four (GoF), that is Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides [Gamma et al.95].

Today, design patterns are widely accepted as useful tools for guiding and documenting the design of object-oriented software systems. Design patterns play many roles in the development process. They provide a common vocabulary for design, they reduce system complexity by naming and defining abstractions, they constitute a base of experience for building reusable software, and they act as building blocks from which more complex designs can be built.

Design patterns can be considered reusable microarchitectures that contribute to an overall system architecture. Ideally, they capture the intent behind a design by identifying the component objects, their collaborations, and the distribution of responsibilities. The purpose of this book is to show how this intention can be made explicit, based on the notion of contract. A software contract captures mutual obligations and benefits among stakeholder components, for example between the client of a service and its suppliers (including subclasses). Contracts strengthen and deepen interface specifications. Along the lines of abstract data type theory, a common way of specifying software contracts is to use boolean assertions called pre- and post-conditions for each service offered, as well as class invariants for defining general consistency properties. Then the contract reads as follows: the client should only ask a supplier for a service in a state where the class invariant and the precondition of the service are respected. In return, the supplier promises that the work specified in the postcondition will be done, and the class invariant is still respected. In this way rights and obligations of both client and supplier are clearly delineated, along with their responsibilities.

This idea was first implemented in the Eiffel language [Meyer92a] under the name Design by Contract, and is now available with a range of expressive power into several other programming languages (such as Java) and even in the Unified Modeling Language (UML) with the Object Constraint Language (OCL) [Warmer et al.98]. Like the design pattern idea, the design by contract is not really tied to any language, but we need to choose one for describing concrete examples. We settled on Eiffel because it provides the right paradigms to address the construction of large, high-quality object-oriented software systems while staying quite easy to master. This book can thus be used as a GoF's companion for the Eiffel community; however we believe this book will also be most useful to people more generally interested in obtaining the greatest benefit from the Design Patterns ideas in a quality based software engineering framework. We describe many examples using the UML notation and we also explain how Design by Contract can be used with Java through the iContract tool [Kramer98] (See Appendix C.1).

The first Chapter is a short introduction to the notion of Design Patterns, and to their role in the software lifecycle. The second Chapter sets the arguments for an optimal use of Design Patterns in a quality oriented software engineering process, based on Design by Contract and associated technologies.

The second part of this book contains three Chapters presenting how the GoF creational, structural and behavioral patterns can be augmented with contracts. For each of these design patterns, we simply recall its name and intent (as in the GoF book) before discussing specific implementation issues and providing a complete, ready to be compiled and run example of the use of the pattern in a toy application. Only the most interesting parts of the source code are presented and discussed in this book: the full source code of each example, ready to be compiled and run with a free Eiffel compiler is available on this book Web site (see Appendix D for the details).

The third part of the book illustrates how one can build on design patterns to solve interesting software engineering problems. Chapter 6 illustrates how Creational Design Patterns can be leveraged to simplify Software Configuration Management without impacting on the application overall performance. Chapter 7 describes how to combine patterns for building graphical user interfaces.

Finally, the last part of the book contains a detailed glossary intended to make the book understandable to those who are not perfectly familiar with object-oriented design concepts and terminology (Appendix A). It closes with a set of Design Pattern and Design by Contract pointers (FAQ, WWW, News, etc., cf. Appendix B) and a presentation of Reto Kramer's iContract tool allowing Design by Contract to be used with Java (Appendix C.1), as well as an overview of the OCL allowing Design by Contract to be used with the UML (Appendix C.2).


We would like to thank M. Thomas, Tim Ross, Ian Gilmour, and Alain Le Guennec, who read early versions of this book and gave us a lot of feedback as well as many pertinent suggestions.

We are also grateful to Reto Kramer for allowing us to reproduce a portion of the iContract documentation (Appendix C.1).

We have a special debt toward Dominique Colnet, the author of the GNU Eiffel compiler (also known as SmallEiffel), for the many insights he gave us on the inner working of his compiler and his contribution to Chapter 6. Dominique also suggested an improvement to the Singleton pattern implementation.

J.-M. Jézéquel would like to thank Professor Yonezawa from the University of Tokyo, for hosting him as a visiting scientist to Japan during most of 1996, when this book started to take shape.

M. Train would like to thank Rémi Houdaille for the many ideas he developped and those he helped define precisely; and Bruno Borghi for his deep insights in sofware development processes.

Finally we would like to thank our editor, Addison-Wesley, for their constant support in making this book take shape.


Design Patterns FAQ

The official unofficial or maybe it's the unofficial official Patterns FAQ ( is maintained by Doug Lea.

 Mailing Lists

There are several mailing lists dealing with patterns and/or Eiffel. Among them:
[] is for presenting and describing software patterns. They don't have to be object-oriented or design patterns, though most of them are. To subscribe, send a request to containing the word subscribe in the Subject field.

[] is for presenting and creating patterns on concurrency, distribution, and IPCs. To subscribe, send a request to containing a single word subscribe in the Subject field. [] is for discussion of patterns in general, i.e., for discussing how to find patterns, how to organize them, or the meaning of patterns, but not necessarily about particular patterns. To subscribe, send a request to containing a single word subscribe in the Subject field.

[] is about the design patterns in the Gang of Four's book. To subscribe, send a request to containing a single word subscribe in the Subject field.

[] is for discussions of OO design patterns and idioms in the Eiffel programming language. This mailing list is being produced by Eiffel programmers who are working together on a volunteer basis to generate a catalog of object-oriented design patterns expressed in Eiffel. To subscribe, send an e-mail to eiffel-patterns-subscribe@egroups, or subscribe online from This list is maintained by Stuart Hungerford (

[] is for reviewing and discussing the patterns described in the book Pattern-Oriented Software-Achitecture -- A System of Patterns To subscribe, send a request to containing a single word subscribe in the Subject field.

 World Wide Web


to top of this page