Design by contract

Design by contract

Design by Contract (DbC) or Programming by Contract is an approach to designing computer software. It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants. These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts.

Design by Contract is a registered trademark[1] of Eiffel Software in the United States. Other names are used where trademark infringement need be avoided. Microsoft calls its implementation 'Code Contracts'[2].



The term was coined by Bertrand Meyer in connection with his design of the Eiffel programming language and first described in various articles starting in 1986[3][4][5] and the two successive editions (1988, 1997) of his book Object-Oriented Software Construction. Eiffel Software applied for trademark registration for Design by Contract in December 2003, and it was granted in December 2004.[6][7] The current owner of this trademark is Eiffel Software.[1][8]

Design by Contract has its roots in work on formal verification, formal specification and Hoare logic. The original contributions include:

  • A clear metaphor to guide the design process
  • The application to inheritance, in particular a formalism for redefinition and dynamic binding
  • The application to exception handling
  • The connection with automatic software documentation


The central idea of DbC is a metaphor on how elements of a software system collaborate with each other, on the basis of mutual obligations and benefits. The metaphor comes from business life, where a "client" and a "supplier" agree on a "contract" which defines for example that:

  • The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit).
  • The client must pay the fee (obligation) and is entitled to get the product (benefit).
  • Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts.

Similarly, if a routine from a class in object-oriented programming provides a certain functionality, it may:

  • Expect a certain condition to be guaranteed on entry by any client module that calls it: the routine's precondition—an obligation for the client, and a benefit for the supplier (the routine itself), as it frees it from having to handle cases outside of the precondition.
  • Guarantee a certain property on exit: the routine's postcondition—an obligation for the supplier, and obviously a benefit (the main benefit of calling the routine) for the client.
  • Maintain a certain property, assumed on entry and guaranteed on exit: the class invariant.

The contract is the formalization of these obligations and benefits. One could summarize design by contract by the "three questions" that the designer must repeatedly ask:

  • What does it expect?
  • What does it guarantee?
  • What does it maintain?

Many languages have facilities to make assertions like these. However, DbC considers these contracts to be so crucial to software correctness that they should be part of the design process. In effect, DbC advocates writing the assertions first.

The notion of a contract extends down to the method/procedure level; the contract for each method will normally contain the following pieces of information:

  • Acceptable and unacceptable input values or types, and their meanings
  • Return values or types, and their meanings
  • Error and exception conditions values or types, that can occur, and their meanings
  • Side effects
  • Preconditions
  • Postconditions
  • Invariants
  • (more rarely) Performance guarantees, e.g. for time or space used

Subclasses in an inheritance hierarchy are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them). These rules approximate behavioral subtyping.

All class relationships are between Client classes and Supplier classes. A Client class is obliged to make calls to Supplier features where the resulting state of the Supplier is not violated by the Client call. Subsequently, the Supplier is obliged to provide a return state and data that does not violate the state requirements of the Client. For instance, a Supplier data buffer may require that data is present in the buffer when a delete feature is called. Subsequently, the Supplier guarantees to the client that when a delete feature finishes its work, the data item will, indeed, be deleted from the buffer. Other Design Contracts are concepts of "Class Invariant". The Class Invariant guarantees (for the local class) that the state of the class will be maintained within specified tolerances at the end of each feature execution.

When using contracts, a supplier should not try to verify that the contract conditions are satisfied; the general idea is that code should "fail hard", with contract verification being the safety net. DbC's "fail hard" property simplifies the debugging of contract behavior as the intended behaviour of each routine is clearly specified. This distinguishes it markedly from a related practice known as defensive programming, where the supplier is responsible for figuring out what to do when a precondition is broken. More often than not, the supplier throws an exception to inform the client that the precondition has been broken, and in both cases—DbC and defensive programming—the client must figure out how to respond to that. DbC makes the supplier's job easier.

Design By Contract also defines criteria for correctness for a software module:

  • If the class invariant AND precondition are true before a supplier is called by a client, then the invariant AND the postcondition will be true after the service has been completed.
  • When making calls to a Supplier, a software module should not violate the Supplier's preconditions.

Because the contract conditions should never be violated in program execution, they can be either left in as debugging code or removed from the production version of the code altogether for performance reasons.

Design by Contract can also facilitate code reuse, since the contract for each piece of code is fully documented. The contracts for a module can be regarded as a form of software documentation for the behavior of that module.

Relationship with software testing

Unit testing tests a module in isolation, to check that it meets its contract assuming its subcontractors meet theirs. Integration testing checks whether the various modules are working properly together.

Language support

Languages with native support

Languages that implement most DbC features natively include Cobra, D[9], Eiffel, Fortress, Lisaac, Nice, Oxygene (formerly Chrome), Racket (including higher order contracts, and emphasizing that contract violations must blame the guilty party and must do so with an accurate explanation[10]), Sather, SPARK (via static analysis of Ada programs), Spec#, Vala, VDM, and languages that are built on top of the Microsoft .NET framework version 4.x (C#, VB.NET) through the use of the System.Diagnostics.Contract namespace.

Languages with third-party support

Various libraries, preprocessors and other tools have been developed for existing programming languages without native Design by Contract support:

Generic tools

See also


  1. ^ a b Current status of United States Patent and Trademark Office registration for "DESIGN BY CONTRACT"
  2. ^ Code Contracts
  3. ^ Meyer, Bertrand: Design by Contract, Technical Report TR-EI-12/CO, Interactive Software Engineering Inc., 1986
  4. ^ Meyer, Bertrand: Design by Contract, in Advances in Object-Oriented Software Engineering, eds. D. Mandrioli and B. Meyer, Prentice Hall, 1991, pp. 1–50
  5. ^ Meyer, Bertrand: Applying "Design by Contract", in Computer (IEEE), 25, 10, October 1992, pp. 40–51, also available online
  6. ^ United States Patent and Trademark Office registration for "DESIGN BY CONTRACT"
  7. ^ United States Patent and Trademark Office registration for the graphic design with words "Design by Contract"
  8. ^ Current status of United States Patent and Trademark Office registration for the graphic design with words "Design by Contract"
  9. ^ Bright, Walter (2006-08-20). "D Programming Language, Contract Programming". Digital Mars. Retrieved 2006-10-06. 
  10. ^ Findler, Felleisen Contracts for Higher-Order Functions


  • Mitchell, Richard, and McKim, Jim: Design by Contract: by example, Addison-Wesley, 2002
  • A wikibook describing DBC closely to the original model.
  • McNeile, Ashley: A framework for the semantics of behavioral contracts. Proceedings of the Second International Workshop on Behaviour Modelling: Foundation and Applications (BM-FA '10). ACM, New York, NY, USA, 2010. This paper discusses generalized notions of Contract and Substitutability.

External links

Wikimedia Foundation. 2010.

Игры ⚽ Нужен реферат?

Look at other dictionaries:

  • Design by contract — (kurz DbC; englisch für Entwurf gemäß Vertrag) oder Programming by Contract ist ein Konzept aus dem Bereich der Softwareentwicklung. Ziel ist das reibungslose Zusammenspiel einzelner Programmmodule durch die Definition formaler „Verträge“ zur… …   Deutsch Wikipedia

  • Design By Contract — (englisch Entwurf gemäß Vertrag) oder kurz DBC ist ein Konzept aus dem Bereich der Softwareentwicklung. Ziel ist das reibungslose Zusammenspiel einzelner Programmmodule durch die Definition formaler Verträge zur Verwendung von Schnittstellen, die …   Deutsch Wikipedia

  • Design by Contract — (englisch Entwurf gemäß Vertrag) oder kurz DBC ist ein Konzept aus dem Bereich der Softwareentwicklung. Ziel ist das reibungslose Zusammenspiel einzelner Programmmodule durch die Definition formaler Verträge zur Verwendung von Schnittstellen, die …   Deutsch Wikipedia

  • Contract — law …   Wikipedia

  • Contract (disambiguation) — A contract is a promise or an agreement made of a set of promises, the breach of which is recognized by the law and for which legal remedies can be provided Contract may also refer to: Contents 1 Academics and education 2 Business 3 Computers and …   Wikipedia

  • Design–build — Design build (or design/build, and abbreviated D–B or D/B accordingly) is a project delivery system used in the construction industry. It is a method to deliver a project in which the design and construction services are contracted by a single… …   Wikipedia

  • Contract — • The canonical and moralist doctrine on this subject is a development of that contained in the Roman civil law. In civil law, a contract is defined as the union of several persons in a coincident expression of will by which their legal relations …   Catholic encyclopedia

  • Contract cheating — is a form of academic dishonesty in which students get others to complete their coursework for them by putting it out to tender.[1][2][3][4] The term was coined in a 2006 study[5] by Thomas Lancaster …   Wikipedia

  • Design of a Decade 1986/1996 — Greatest hits album by Janet Jackson Released October 10, 1995 …   Wikipedia

  • Design 1047 battlecruiser — A plan and profile of Nevesbu s Project 1047; it is not specified if this depicts the final design.[1] Class overview Name …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”