Design by contract

The "Contract" part of Design by Contract is a metaphor relating real-world contracts. For instance, a Acme Construction may sign a business contract to build a skyscraper, for a price of $100 million. Legally, the contract means that Acme Construction must build the skyscraper to at least the standard agreed, and may demand $100 million dollars (but no more) as payment.

If we consider this business arrangement from the perspective of Acme Construction, we can regard the contract as a set of preconditions and postconditions:

Preconditions: The building must be built on time and to the required standard. Postconditions: Acme Construction must receive $100 million dollars.

Acme Construction is free to build the building to a higher standard (if they want to) but not a lower standard. Also, they might choose to accept less than $100 million dollars as payment (for some reason) but they cannot suddenly demand more.

Similarly, Design by Contract specifies preconditions and postconditions for each method. If that method is called, it "promises" or "guarantees" to satisfy a number of postconditions, but only provided the accompanying preconditions are met.

Let us suppose we are writing a class called Door to run automatic doors. This class defines a method called open(). Its pre/postconditions might be:

Preconditions: It is within the opening hours of the building. The alarm system is off. Postconditions: The door is opened.

Suppose we then wish to implement a security-enabled door as a subclass of Door. The open() method for SecurityDoor would have the following new conditions:

Preconditions: The user has swiped a valid card. It is within the opening hours of the building. The alarm system is off. Postconditions: The door is opened for only ten seconds.