Design by Contract DbC

DbC views software component interaction as Client-Server or Client-Supplier Model.
Part of DbC rules:
- A precondition violation is the manifestation of a bug in the client.
- A postcondition violation is the manifestation of a bug in the supplier.

The simple explanation of the above is that there must be a contract/condition in place when two/more software components interact in order to produce a correct output.

Say there exist a routine/function, SQRT(x), which for any positive interger/number x passed to it, it returns the square-root of such positive integer.

In this case, the SQRTt() will be called the #Server while a Second function that is supposed to call SQRT() will be called #Client.

Part of the condition that would make SQRT() or the Server to work correctly is that the client must pass in a +ve. So the client or the function invoking must sure it is satistied or checked before invoking SQRT(). Failure to do so is a bug on the client side(i.e. precondition not satisfied).

Failure of the Server(SQRT() in this case) to produce the correct output even after the client has fulfilled it condition is a manifestation of an error on the server.

Moving forward, checking whether x is positive before proceeding with the actual square-root computation defining SQRT() as follow will be redundant:

A sample #python illustration 👇 :
def SQRT(x):
check x is +ve before further computation #-> defensive progamming

DbC goes against defensive programming paradigm which is believed to affect perfomance(due to redundant checks)