Design by Contract® is a method used to develop software that relies on the establishment of well-defined interface parameters, or contracts, for all parts of a program. Although Design by Contract® can be viewed as a conceptual development style that is implemented through documentation or modeling, it more widely is used to refer to a native or third-party mechanism within some programming languages that actually requires the implicit coding of the contracts within a program. The goal in using Design by Contract® is that a program will be developed and, eventually, coded in a much more complete fashion that removes more trivial errors, while enforcement of the contracts by the supporting language makes any residual errors easily found and captured. A program that uses contracts for functions and classes can have a more modular design in which individual classes can be reused easily in other programs because of the clear definition of their contracts.
The basis for the Design by Contract® programming philosophy is the idea of real-world business contracts. In this model, each method and class in an object oriented program defines a contract by which any other method or object interacting with it must abide. Each class also can have a contract, called a class invariant, that it must follow internally to ensure that outside contracts do not compromise its ability to function.
The two parts of a contract that are most important during design and coding are the preconditions and the post-conditions. These two parts of the Design by Contract® model define the state of the program before a method is called and the state of the program after the method has completed executing. Other parts of a contract can vary by implementation but might include cross-references to other modules, synchronization conditions and order-of-execution requirements.
By developing contracts for each class and method, the interaction of the different parts of a program can easily be mapped and predicted. The enforcement of the contracts, either through the use of assertions or other mechanisms, also ensures that the program will not attempt to execute if there is a violation of contracts, because any output produced in that state would technically be invalid anyway. When implemented as a native language feature, Design by Contract® can help to ensure that a final product will operate as expected with little chance for unforeseen errors.
Some of the complications that come with use of the Design by Contract® philosophy include longer design times and more granular development of a system before coding begins, which can sometimes be difficult with a large project. More practically, the contract validation mechanism used in a programming language that natively supports contracts can slow down program execution. A poor understanding of the Design by Contract® methodology can lead to a program that uses contracts to perform basic error checking, potentially leading to an application that is prone to sudden crashes after release.