Editing Design by contract (section)

==Description==
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" that 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 the [[Method_(computer_science)|method]] of a [[class (computer programming)|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 method's [[precondition]]—an obligation for the client, and a benefit for the supplier (the method itself), as it frees it from having to handle cases outside of the precondition.
* Guarantee a certain property on exit: the method's [[postcondition]]—an obligation for the supplier, and obviously a benefit (the main benefit of calling the method) for the client.
* Maintain a certain property, assumed on entry and guaranteed on exit: the [[class invariant]].

The contract is semantically equivalent to a [[Hoare triple]] which formalises the obligations.  This can be summarised by the "three questions" that the designer must repeatedly answer in the contract:
* What does the contract expect?
* What does the contract guarantee?
* What does the contract maintain?

Many [[programming language]]s have facilities to make [[assertion (software development)|assertion]]s like these. However, DbC considers these contracts to be so crucial to [[correctness (computer science)|software correctness]] that they should be part of the design process. In effect, DbC advocates [[Test-driven_development|writing the assertions first]].{{cn|date=June 2019}} Contracts can be written by [[Comment (computer programming)|code comments]], enforced by a [[test suite]], or both, even if there is no special language support for contracts.

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:{{Citation needed|reason=reliable source needed for the following list|date=September 2012}}
* Acceptable and unacceptable input values or types, and their meanings
* Return values or types, and their meanings
* Error and [[Exception handling|exception]] condition values or types that can occur, and their meanings
* [[Side effect (computer science)|Side effects]]
* [[Precondition]]s
* [[Postcondition]]s
* [[Invariant (computer science)|Invariant]]s
* (more rarely) Performance guarantees, e.g. for time or space used

Subclasses in an [[Inheritance (object-oriented programming)|inheritance hierarchy]] are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them). These rules approximate [[Liskov substitution principle|behavioural 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—a practice known as [[offensive programming]]—the general idea being 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 method is clearly specified.

This approach differs substantially from that of [[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 alike—the client must figure out how to respond to that. In such cases, 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.

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.