CSC/ECE 517 Fall 2011/ch18 6a sc: Difference between revisions
Line 21: | Line 21: | ||
Before enters a method or routine, a [http://en.wikipedia.org/wiki/Precondition pre-condition] that must be satisfied by the consumer of the routine. Each routine ends with [http://en.wikipedia.org/wiki/Postcondition post-conditions] which the supplier guarantees to be true (if and only if the preconditions were met). Also, each class has an [http://en.wikipedia.org/wiki/Class_invariant invariant] which must be satisfied after any changes to an object represented by the class. In the other words, the invariant guarantees the object is in a valid state. [http://www.cs.unc.edu/~stotts/204/contract.html (2)] | Before enters a method or routine, a [http://en.wikipedia.org/wiki/Precondition pre-condition] that must be satisfied by the consumer of the routine. Each routine ends with [http://en.wikipedia.org/wiki/Postcondition post-conditions] which the supplier guarantees to be true (if and only if the preconditions were met). Also, each class has an [http://en.wikipedia.org/wiki/Class_invariant invariant] which must be satisfied after any changes to an object represented by the class. In the other words, the invariant guarantees the object is in a valid state. [http://www.cs.unc.edu/~stotts/204/contract.html (2)] | ||
<br><br> | <br><br> | ||
===A Java Example=== | |||
Here is a Java example shows where the checks are placed. | |||
<pre> | |||
class Supplier{ //the supplier class | |||
public Supplier() | |||
{ | |||
//some code that initialize supplier constructor | |||
checkInvariant(); //verify class invarient | |||
} | |||
public supplier_method(Data data) | |||
{ | |||
//some actions performed by supplier method | |||
postCondition(); //check if we have done what has been promised | |||
checkInvarient(); //verify class invarient | |||
} | |||
} | |||
class Client { // the client class | |||
public client_method (Data data){ //client method, calls supplier method | |||
Supplier s = new Supplier(); //initialize supplier constructor | |||
preCondition(data); //verify the preCondition before enter supplier method | |||
s.supplier_method(data); | |||
} | |||
} | |||
</pre> | |||
<br> | |||
===Obligations and Benefits=== | |||
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" which documents that: | 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" which documents that: | ||
* The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit). | * The supplier must provide a certain product (obligation) and is entitled to expect that the client has paid its fee (benefit). |
Revision as of 20:05, 15 November 2011
Programming by Contract
Common programming errors
Programming by contract
Programming by Contract or Design by Contract (DbC) was first introduced by Bertrand Meyer, the creator of Eiffel programming language. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses pre-conditions and post-conditions to document or programmatically assert the change in state caused by a piece of a program. (1)
Background
Programming by Contract or Design by Contract (DbC) has its roots in work on formal verification, formal specification and Hoare logic. The original contributions includes:
- A clear metaphor to guide the design process.
- The application to inheritance, in particular a formalism for redefinition and dynamic binding.
- The application to exception handling.
- The connection with automatic software documentation.
Methodology
Programming by Contract creates a contract between the software developer and software user - in Meyer's terms the supplier and the consumer.
Before enters a method or routine, a pre-condition that must be satisfied by the consumer of the routine. Each routine ends with post-conditions which the supplier guarantees to be true (if and only if the preconditions were met). Also, each class has an invariant which must be satisfied after any changes to an object represented by the class. In the other words, the invariant guarantees the object is in a valid state. (2)
A Java Example
Here is a Java example shows where the checks are placed.
class Supplier{ //the supplier class public Supplier() { //some code that initialize supplier constructor checkInvariant(); //verify class invarient } public supplier_method(Data data) { //some actions performed by supplier method postCondition(); //check if we have done what has been promised checkInvarient(); //verify class invarient } } class Client { // the client class public client_method (Data data){ //client method, calls supplier method Supplier s = new Supplier(); //initialize supplier constructor preCondition(data); //verify the preCondition before enter supplier method s.supplier_method(data); } }
Obligations and Benefits
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" which documents 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. (3)
Benifit
How does it work with inheritance?
Examples
Example 1
Example 2
Example 3
Summary
References
1. Cunningham & Cunningham, Inc., Design by Contract
2. University of North Carolina
3. Eiffel Software, Design by Contract
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html