|
|
| Line 1: |
Line 1: |
| '''Advantages and Disadvantages of Programming by Contract'''
| |
|
| |
|
| == Introduction of Contract Programming ==
| |
|
| |
| Contracts are a breakthrough technique to reduce the programming effort for large projects. Contracts are the concept of preconditions, postconditions, errors, and invariants. These specifications of "contract" define the interface of different element of software includes method, class, module and so on. In the following of introduction section, we provide some examples of different assertions.
| |
|
| |
| ===Assert contract===
| |
| The most basic contract is the assert. An assert inserts a checkable expression into the code, and that expression must evaluate to true:
| |
| <pre>
| |
| assert(expression);
| |
| </pre>
| |
| an assert in function bodies works by throwing an AssertError, which can be caught and handled. Catching the contract violation is useful when the code must deal with errant uses by other code, when it must be failure proof, and as a useful tool for debugging.
| |
|
| |
| ===Pre and Post contract ===
| |
| The pre contracts specify the preconditions before a statement is executed. The most typical use of this would be in validating the parameters to a function. The post contracts validate the result of the statement. The most typical use of this would be in validating the return value of a function and of any side effects it has. The syntax is:
| |
| <pre>
| |
| long square_root(long x)
| |
| in
| |
| {
| |
| assert(x >= 0);
| |
| }
| |
| out (result)
| |
| {
| |
| assert((result * result) <= x && (result+1) * (result+1) >= x);
| |
| }
| |
| body
| |
| {
| |
| return cast(long)std.math.sqrt(cast(real)x);
| |
| }
| |
| </pre>
| |
| ===In, Out and Inheritance ===
| |
| If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied. Overriding functions then becomes a process of loosening the in contracts.
| |
|
| |
| ===Class Invariants ===
| |
| Class invariants are used to specify characteristics of a class that always must be true (except while executing a member function). They are described in Classes.
| |
|
| |
| for detail information of contract, please refers to the helpful reading list in [2].
| |
|
| |
| ==The advantages of Contract Programming==
| |
|
| |
| * A better understanding of the object-oriented method and, more generally, of software construction.
| |
| * A systematic approach to building bug-free object-oriented systems.
| |
| * An effective framework for debugging, testing and, more generally, quality assurance.
| |
| * A method for documenting software components.
| |
| * Better understanding and control of the inheritance mechanism.
| |
| * A technique for dealing with abnormal cases, leading to a safe and effective language construct for exception handling.
| |
|
| |
|
| |
| == The disadvantages of Contract Programming ==
| |
|
| |
| == References ==
| |
|
| |
| [1] wiki page of "Design by Contract", http://en.wikipedia.org/wiki/Design_by_contract
| |
|
| |
| [2] reading list of contract, http://www.eecs.northwestern.edu/~robby/contract-reading-list/
| |