CSC/ECE 517 Fall 2007/wiki3 2 at: Difference between revisions
No edit summary |
|||
Line 6: | Line 6: | ||
Programming by Contract is a way of specifying the behavior of a function, and the name arises from its formal similarity to a legal contract. The key concept is viewing the relationship between a class and its clients as a formal agreement, expressing each party’s rights and obligations. Defining a precondition and a postcondition for a routine is a way to define a contract that binds the routine and its callers. The precondition states the properties that must hold whenever the routine is called; the postcondition states the properties that the routine guarantees when it returns. | Programming by Contract is a way of specifying the behavior of a function, and the name arises from its formal similarity to a legal contract. The key concept is viewing the relationship between a class and its clients as a formal agreement, expressing each party’s rights and obligations. Defining a precondition and a postcondition for a routine is a way to define a contract that binds the routine and its callers. The precondition states the properties that must hold whenever the routine is called; the postcondition states the properties that the routine guarantees when it returns. | ||
<br> | <br> | ||
By associating clauses <b>require pre </b> and <b>ensure</b> | By associating clauses <b>require pre </b> and <b>ensure post</b> with a routine <b>r</b>, the class tells its clients: | ||
<pre> | |||
a final state in which post is satisfied.” | If you promise to call <b>r</b> with <b>pre</b> satisfied then I, in return, promise to deliver | ||
a final state in which <b>post</b> is satisfied.” | |||
</pre> | |||
Revision as of 18:44, 27 November 2007
Topic:
In class, we had some difficulty coming up with good examples of programming by contract. Find some concise ones that illustrate the principle well, and are accessible to a general audience of programmers.
Programming by contract
Programming by Contract is a way of specifying the behavior of a function, and the name arises from its formal similarity to a legal contract. The key concept is viewing the relationship between a class and its clients as a formal agreement, expressing each party’s rights and obligations. Defining a precondition and a postcondition for a routine is a way to define a contract that binds the routine and its callers. The precondition states the properties that must hold whenever the routine is called; the postcondition states the properties that the routine guarantees when it returns.
By associating clauses require pre and ensure post with a routine r, the class tells its clients:
If you promise to call <b>r</b> with <b>pre</b> satisfied then I, in return, promise to deliver a final state in which <b>post</b> is satisfied.”
Consider the following example:
class STACK [G] feature ...Declaration of the features: count, empty, full, put, remove, item end
Before considering implementation issues, however, it is important to note that the routines are characterized by strong semantic properties, independent of any specific representation.
For example:
• Routines remove and item are only applicable if the number of elements is not zero.
• put increases the number of elements by one; remove decreases it by one.
Such properties are part of the abstract data type specification, and even people who do not use any approach remotely as formal as ADTs understand them implicitly. But in common approaches to software construction software texts reveal no trace of them. Through routine preconditions and postconditions you can turn them into explicit elements of the software.
See Also
http://en.wikibooks.org/wiki/Computer_programming/Design_by_Contract
http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm
http://www.cs.uno.edu/~c1581/Labs2006/lab7/lab7.htm
http://www.phpunit.de/pocket_guide/3.2/en/test-first-programming.html
http://www.python.org/dev/peps/pep-0316/
http://www.artima.com/cppsource/deepspace2.html
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
http://www.csc.calpoly.edu/~dstearns/SeniorProjectsWWW/Rideg/dbc.html
References
[1] http://www.ibm.com/developerworks/rational/library/455.html#N10324
[2] http://archive.eiffel.com/doc/manuals/technology/contract/page.html
[3] http://www.wayforward.net/pycontract/
[4] http://www.patentstorm.us/patents/6442750-description.html
[5] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1613.pdf