Design by contract

Where this assumption is considered too risky (as in multi-channel or distributed computing), the inverse approach is taken, meaning that the server component tests that all relevant preconditions hold true (before, or while, processing the client component's request) and replies with a suitable error message if not.

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[1][2][3] and the two successive editions (1988, 1997) of his book Object-Oriented Software Construction.

The original contributions include: 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.

This can be summarised by the "three questions" that the designer must repeatedly answer in the contract: Many programming 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.

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.

The advantage of internal self-tests is that they can detect errors before they manifest themselves as invalid results observed by the client.