Design Patterns with Contracts

• Authors: Jean-Marc Jezequel;Michel Train;Christine Mingins
• Venue: Design Patterns with Contracts
• Year: 1999

From the Book:PREFACE: The idea of systematically identifying and documenting design patterns as autonomous entities was born in the late 1980s. It was brought into the mainstream by the Hillside Group, such people as Beck, Ward, Coplien, Booch, Kerth, and Johnson. However, the main event in this emerging field was the 1995 publication of the book Design Patterns: Elements of Reusable Object-Oriented Software (Gamma et al., 1995) by the so-called Gang of Four (GoF): Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. 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, reduce system complexity by naming and defining abstractions, constitute a base of experience for building reusable software, and 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 the suppliers, including subclasses, of that service. Contracts strengthen and deepen interface specifications. Along the lines of abstract data type theory, a common way ofspecifyingsoftware contracts is to use Boolean assertions called pre- and postconditions for each service offered, as well as class invariants for defining general consistency properties. Then the contract reads as follows: The client should ask a supplier for a service only in a state in which 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 that the class invariant will still be respected. In this way, rights and obligations of both the client and the supplier are clearly delineated, along with their responsibilities. This idea, first implemented in the Eiffel language (Meyer, 1992a) under the name Design by Contract, is now available in several other programming languages, such as Java, and even in the Unified Modeling Language (UML) with the Object Constraint Language (OCL) (Warmer and Kleppe, 1999). Like the design pattern idea, the Design by Contract is not tied to any particular 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 and is quite easy to master. This book can thus be used as a GoF's companion for the Eiffel community; however, we believe that 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, in Section C.1, how Design by Contract can be used with Java through the iContract tool (Kramer, 1998). Part I of this book establishes the framework for using design patterns. Chapter 1 introduces the notion of design patterns and their role in the software life cycle. Chapter 2 outlines 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 three chapters in Part II explain how the GoF creational, structural, and behavioral patterns can be augmented with contracts. For each of these design patterns, we simply review its name and intent from the GoF book and then discuss specific implementation issues and provide a complete example, ready to be compiled and run, of the use of the pattern in a hypothetical 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's Web site (see Appendix D for the details). Part III illustrates how one can build on design patterns to solve interesting software engineering problems. Chapter 6 explains how creational design patterns can be leveraged to simplify software configuration management without impacting on the application's overall performance. Chapter 7 discusses how to combine patterns for building graphical user interfaces. Finally, the book contains a detailed glossary (Appendix A) of object-oriented design concepts and terminology, pointers to further information on design patterns and Design by Contract (Appendix B) and a discussion of Design by Contract in other languages (Appendix C). Appendix D tells you how to get more information about this book.