Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-17T01:55:45Z

Che: /* Summary */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=
It would not be wrong to say that no software in the world is bug free. A lot of bugs in software can be attributed to the programming errors that the programmers commonly make. The most common of them are: [http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html (4)]

*While considering possibilities, the programmer misses out on some
*Cut-and-paste programming
*Inflexible code that cannot adapt to changes that maybe needed of it in future
*Lack of error checking
*Software reuse
*Lack of mechanisms to recover from errors in a graceful manner
 
One of the several things essential in making bug free software a reality is "Programming by contract". It helps programmers develop robust software.

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of the [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 (callee) and the consumer (caller/client).
 
Before entering a method or routine, a [http://en.wikipedia.org/wiki/Precondition pre-condition] must be satisfied by the consumer of the routine. Each routine ends with a [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 are represented by the class. In other words, the invariant guarantees the object is in a valid state. [http://www.cs.unc.edu/~stotts/204/contract.html (2)]
 
If the consumer tries to call the method without meeting the preconditions, it can result in unexpected behavior. The program could crash or run in a loop forever. It may also deceptively generate garbage, while giving an impression that it is running correctly.
===A Java Example===
Here is a Java example that shows where the checks can be placed.
<pre>
class Supplier{ //the supplier class
public Supplier()
{
//some code that initializes the supplier constructor
checkInvariant(); //verify class invariant
}
public supplier_method(Data data)
{
//some actions performed by supplier method
postCondition(); //check if we have done what has been promised
checkInvariant(); //verify class invariant
}
}

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 calling the supplier method
s.supplier_method(data);
}
}
</pre>
 

===Design by Contract Metaphor===
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
We can use the previous Java example to show the relationship between obligation and benefit.
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition() is satisfied by client_method
|}

==Apply Programming by Contract to Applications==

===Inheritance===
When programming by contract is used with inheritance, a subcontract is added to the subclass. According to this subcontract and in accordance with the Liskov Substitution Principle [http://www.objectmentor.com/resources/articles/lsp.pdf (5)], an overridden method in the subclass may have preconditions that are as weak as or weaker than the preconditions of the base class, and postconditions that are as strong as or stronger than the postconditions of the base class. We can see this in the following example:
 
<pre>
class A
{
public int foo(int x)
{
assert(1<x<3); // pre-condition
...
assert(result<15); //post-condition
return result;
}
}

class B extends A
{
public int foo(int x)
{
assert(0<x<5); //weakened pre-condition
...
assert(result<3); //strengthened post-condition
return result;
}

}
</pre>

===Exception Handling===
When it is necessary to impose restrictions on the input given to a method, rather than just stating preconditions in the documentation, exception handling can be used. If the input, say an argument to the method is illegal, then an exception an be thrown. This way, the program will work for all inputs. This practice of defending against illegal input is referred to as [http://en.wikipedia.org/wiki/Defensive_programming "Defensive Programming"].
 
The exception handling mechanism helps the user catch errors and handle them appropriately. It also makes sense to use it because the likelihood of errors occurring and illegal input being given to methods is very high. However, the downside to this is that throwing an exception can be very expensive. Let us consider the following example:
 
<pre>
class Search
{
public void BinarySearch(int arr[],int item)
{
Precondition: none
Postcondition: returns the position of the element to be searched if found, else returns -1
If arr[] is not sorted, an IllegalArgumentException is thrown
}

public static void main(String args[])
{
Search s = new Search();
//define an array in which to find an item
s.BinarySearch(arr,item); //the method internally handles all inputs
}
}
</pre>

=Summary=
Design by contract helps programmers identify the consistency conditions that are necessary to the proper functioning of each client-supplier contract, and specify, for each one of the conditions, whose responsibility it is to enforce it.

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
4. [http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html Common Programming Errors]
 
5. [http://www.objectmentor.com/resources/articles/lsp.pdf Liskov Substitution Principle]

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-16T15:59:57Z

Che: /* Exception Handling */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=
It would not be wrong to say that no software in the world is bug free. A lot of bugs in software can be attributed to the programming errors that the programmers commonly make. The most common of them are: [http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html (4)]

*While considering possibilities, the programmer misses out on some
*Cut-and-paste programming
*Inflexible code that cannot adapt to changes that maybe needed of it in future
*Lack of error checking
*Software reuse
*Lack of mechanisms to recover from errors in a graceful manner
 
One of the several things essential in making bug free software a reality is "Programming by contract". It helps programmers develop robust software.

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of the [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 (callee) and the consumer (caller/client).
 
Before entering a method or routine, a [http://en.wikipedia.org/wiki/Precondition pre-condition] must be satisfied by the consumer of the routine. Each routine ends with a [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 are represented by the class. In other words, the invariant guarantees the object is in a valid state. [http://www.cs.unc.edu/~stotts/204/contract.html (2)]
 
If the consumer tries to call the method without meeting the preconditions, it can result in unexpected behavior. The program could crash or run in a loop forever. It may also deceptively generate garbage, while giving an impression that it is running correctly.
===A Java Example===
Here is a Java example that shows where the checks can be placed.
<pre>
class Supplier{ //the supplier class
public Supplier()
{
//some code that initializes the supplier constructor
checkInvariant(); //verify class invariant
}
public supplier_method(Data data)
{
//some actions performed by supplier method
postCondition(); //check if we have done what has been promised
checkInvariant(); //verify class invariant
}
}

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 calling the supplier method
s.supplier_method(data);
}
}
</pre>
 

===Design by Contract Metaphor===
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
We can use the previous Java example to show the relationship between obligation and benefit.
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition() is satisfied by client_method
|}

==Apply Programming by Contract to Applications==

===Inheritance===
When programming by contract is used with inheritance, a subcontract is added to the subclass. According to this subcontract and in accordance with the Liskov Substitution Principle [http://www.objectmentor.com/resources/articles/lsp.pdf (5)], an overridden method in the subclass may have preconditions that are as weak as or weaker than the preconditions of the base class, and postconditions that are as strong as or stronger than the postconditions of the base class. We can see this in the following example:
 
<pre>
class A
{
public int foo(int x)
{
assert(1<x<3); // pre-condition
...
assert(result<15); //post-condition
return result;
}
}

class B extends A
{
public int foo(int x)
{
assert(0<x<5); //weakened pre-condition
...
assert(result<3); //strengthened post-condition
return result;
}

}
</pre>

===Exception Handling===
When it is necessary to impose restrictions on the input given to a method, rather than just stating preconditions in the documentation, exception handling can be used. If the input, say an argument to the method is illegal, then an exception an be thrown. This way, the program will work for all inputs. This practice of defending against illegal input is referred to as [http://en.wikipedia.org/wiki/Defensive_programming "Defensive Programming"].
 
The exception handling mechanism helps the user catch errors and handle them appropriately. It also makes sense to use it because the likelihood of errors occurring and illegal input being given to methods is very high. However, the downside to this is that throwing an exception can be very expensive. Let us consider the following example:
 
<pre>
class Search
{
public void BinarySearch(int arr[],int item)
{
Precondition: none
Postcondition: returns the position of the element to be searched if found, else returns -1
If arr[] is not sorted, an IllegalArgumentException is thrown
}

public static void main(String args[])
{
Search s = new Search();
//define an array in which to find an item
s.BinarySearch(arr,item); //the method internally handles all inputs
}
}
</pre>

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
4. [http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html Common Programming Errors]
 
5. [http://www.objectmentor.com/resources/articles/lsp.pdf Liskov Substitution Principle]

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-16T02:11:36Z

Che: /* Inheritance */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 (callee) and the consumer (caller/client).
 
Before entering a method or routine, a [http://en.wikipedia.org/wiki/Precondition pre-condition] must be satisfied by the consumer of the routine. Each routine ends with a [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 are represented by the class. In other words, the invariant guarantees the object is in a valid state. [http://www.cs.unc.edu/~stotts/204/contract.html (2)]
 
===A Java Example===
Here is a Java example that shows where the checks can be placed.
<pre>
class Supplier{ //the supplier class
public Supplier()
{
//some code that initializes the supplier constructor
checkInvariant(); //verify class invariant
}
public supplier_method(Data data)
{
//some actions performed by supplier method
postCondition(); //check if we have done what has been promised
checkInvariant(); //verify class invariant
}
}

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 calling the supplier method
s.supplier_method(data);
}
}
</pre>
 

===Design by Contract Metaphor===
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
We can use the previous Java example to show the relationship between obligation and benefit.
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition() is satisfied by client_method
|}

==Apply Programming by Contract to Applications==

===Inheritance===
When programming by contract used with inheritance, a subcontracting is added to the inherited class.
The subcontracting may keep or weaken the precondition; it may keep or strengthen the postcondition.
 
<pre>
class A
{
public int foo(int x)
{
assert(1<x<3); // pre-condition
...
assert(result<15); //post-condition
return result;
}
}

class B extends A
{
public int foo(int x)
{
assert(0<x<5); //weakened pre-condition
...
assert(result<3); //strengthened post-condition
return result;
}

}
</pre>

===Exception Handling===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-16T02:11:03Z

Che: /* Inheritance */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 (callee) and the consumer (caller/client).
 
Before entering a method or routine, a [http://en.wikipedia.org/wiki/Precondition pre-condition] must be satisfied by the consumer of the routine. Each routine ends with a [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 are represented by the class. In other words, the invariant guarantees the object is in a valid state. [http://www.cs.unc.edu/~stotts/204/contract.html (2)]
 
===A Java Example===
Here is a Java example that shows where the checks can be placed.
<pre>
class Supplier{ //the supplier class
public Supplier()
{
//some code that initializes the supplier constructor
checkInvariant(); //verify class invariant
}
public supplier_method(Data data)
{
//some actions performed by supplier method
postCondition(); //check if we have done what has been promised
checkInvariant(); //verify class invariant
}
}

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 calling the supplier method
s.supplier_method(data);
}
}
</pre>
 

===Design by Contract Metaphor===
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
We can use the previous Java example to show the relationship between obligation and benefit.
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition() is satisfied by client_method
|}

==Apply Programming by Contract to Applications==

===Inheritance===
When programming by contract used with inheritance, a subcontracting is used in the inherited class.
The subcontracting may keep or weaken the precondition; it may keep or strengthen the postcondition.
 
<pre>
class A
{
public int foo(int x)
{
assert(1<x<3); // pre-condition
...
assert(result<15); //post-condition
return result;
}
}

class B extends A
{
public int foo(int x)
{
assert(0<x<5); //weakened pre-condition
...
assert(result<3); //strengthened post-condition
return result;
}

}
</pre>

===Exception Handling===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T21:42:47Z

Che: /* Examples */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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)]
 
===A Java Example===
Here is a Java example shows where the checks can be 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>
 

===Design by Contract Metaphor===
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
We can use the previous Java example to show the relationship between obligation and benefit.
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition() is satisfied by client_method
|}

==Apply Programming by Contract to Applications==

===Inheritance===

===Exception Handling===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T21:42:23Z

Che: /* How does it work with inheritance? */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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)]
 
===A Java Example===
Here is a Java example shows where the checks can be 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>
 

===Design by Contract Metaphor===
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
We can use the previous Java example to show the relationship between obligation and benefit.
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition() is satisfied by client_method
|}

==Apply Programming by Contract to Applications==

===Inheritance===

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T21:41:59Z

Che: /* Benifit */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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)]
 
===A Java Example===
Here is a Java example shows where the checks can be 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>
 

===Design by Contract Metaphor===
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
We can use the previous Java example to show the relationship between obligation and benefit.
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition() is satisfied by client_method
|}

==Apply Programming by Contract to Applications==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T21:21:12Z

Che: /* Obligations and Benefits */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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)]
 
===A Java Example===
Here is a Java example shows where the checks can be 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>
 

===Design by Contract Metaphor===
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
We can use the previous Java example to show the relationship between obligation and benefit.
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition() is satisfied by client_method
|}

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T21:20:02Z

Che: /* Obligations and Benefits */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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)]
 
===A Java Example===
Here is a Java example shows where the checks can be 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>
 

===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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
We can use the previous Java example to show the relationship between obligation and benefit.
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition() is satisfied by client_method
|}

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T21:18:42Z

Che: /* Obligations and Benefits */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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)]
 
===A Java Example===
Here is a Java example shows where the checks can be 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>
 

===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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition() is satisfied by client_method
|}

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T21:18:06Z

Che: /* Obligations and Benefits */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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)]
 
===A Java Example===
Here is a Java example shows where the checks can be 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>
 

===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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 
{| class="wikitable" border="1"
|-
!
! Obligations
! Benefit
|-
| Client
| Satisfy preCondition()
| Result from supplier_method
|-
| Supplier
| Satisfy postCondition()
| Know that preCondition is satisfied
|}

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T20:05:33Z

Che: /* A Java Example */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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)]
 
===A Java Example===
Here is a Java example shows where the checks can be 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>
 

===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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T20:05:08Z

Che: /* Methodology */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
==Background==
Programming by Contract or [http://en.wikipedia.org/wiki/Design_by_contract Design by Contract (DbC)] has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process.
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding].
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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)]
 
===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>
 
===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. [http://www.eiffel.com/developers/design_by_contract.html (3)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:52:47Z

Che: /* Methodology */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:39:19Z

Che: /* Programming by contract */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:39:06Z

Che: /* Methodology */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:38:53Z

Che: /* Background */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:36:36Z

Che: /* References */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:34:34Z

Che: /* Programming by contract */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:33:45Z

Che: /* References */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
==Background==
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding]
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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 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)]
 
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:33:35Z

Che: /* References */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
==Background==
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding]
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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 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)]
 
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
3. [http://www.eiffel.com/developers/design_by_contract.html Eiffel Software, Design by Contract]
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:32:10Z

Che: /* Methodology */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
==Background==
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding]
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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 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)]
 
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. [http://www.eiffel.com/developers/design_by_contract.html (3)]

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:29:57Z

Che: /* Programming by contract */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
==Background==
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding]
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:29:41Z

Che: /* Programming by contract */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)] 
==Background==
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding]
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:28:57Z

Che: /* History and Background */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
==Background==
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding]
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:28:36Z

Che: /* Programming by contract */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
==History and Background==
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding]
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:28:25Z

Che: /* History and Background */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History and Background==
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding]
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:27:07Z

Che: /* Methodology */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History and Background==
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding]
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:25:46Z

Che: /* History and Background */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History and Background==
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 inheritance], in particular a formalism for redefinition and [http://en.wikipedia.org/wiki/Dynamic_binding_%28computer_science%29 dynamic binding]
* The application to [http://en.wikipedia.org/wiki/Exception_%28computer_science%29 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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:23:42Z

Che: /* History and Background */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History and Background==
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
* A clear metaphor to guide the design process
* The application to [http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:21:18Z

Che: /* History and Background */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History and Background==
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic 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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:19:14Z

Che: /* History and Background */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History and Background==
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in DbC support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
 

==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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:18:20Z

Che: /* History */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History and Background==
Programming by Contract or Design by Contract (DbC) was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in programming by contract support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]
 
Programming by Contract or Design by Contract (DbC) has its roots in work on [http://en.wikipedia.org/wiki/Formal_verification formal verification], [http://en.wikipedia.org/wiki/Formal_specification, formal specification] and [http://en.wikipedia.org/wiki/Hoare_logic Hoare logic]. The original contributions includes:
 

==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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T19:08:57Z

Che: /* Methodology */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History==
The paradigm was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in programming by contract support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]

==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 [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 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)]
 

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T18:40:29Z

Che: /* History */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History==
The paradigm was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in programming by contract support, the concepts can be applied in any language. It uses [http://en.wikipedia.org/wiki/Precondition pre-conditions] and [http://en.wikipedia.org/wiki/Postcondition post-conditions] to document or programmatically assert the change in state caused by a piece of a program. [http://c2.com/cgi/wiki?DesignByContract (1)]

==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 [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 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)]

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T18:39:40Z

Che: /* Methodology */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History==
The paradigm was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in programming by contract 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. [http://c2.com/cgi/wiki?DesignByContract (1)]

==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 [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 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)]

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T18:36:36Z

Che: /* References */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History==
The paradigm was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in programming by contract 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. [http://c2.com/cgi/wiki?DesignByContract (1)]

==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. [http://www.cs.unc.edu/~stotts/204/contract.html (2)]

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T18:36:22Z

Che: /* References */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History==
The paradigm was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in programming by contract 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. [http://c2.com/cgi/wiki?DesignByContract (1)]

==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. [http://www.cs.unc.edu/~stotts/204/contract.html (2)]

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
2. [http://www.cs.unc.edu/~stotts/204/contract.html University of North Carolina]
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T18:34:20Z

Che: /* Methodology */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History==
The paradigm was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in programming by contract 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. [http://c2.com/cgi/wiki?DesignByContract (1)]

==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. [http://www.cs.unc.edu/~stotts/204/contract.html (2)]

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T18:31:36Z

Che: /* History */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==History==
The paradigm was first introduced by [http://c2.com/cgi/wiki?BertrandMeyer Bertrand Meyer], the creator of [http://c2.com/cgi/wiki?EiffelLanguage Eiffel programming language]. Although Eiffel has implemented assertions as built in programming by contract 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. [http://c2.com/cgi/wiki?DesignByContract (1)]

==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.

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
1. [http://c2.com/cgi/wiki?DesignByContract Cunningham & Cunningham, Inc., Design by Contract]
 
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T17:59:19Z

Che: /* References */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T17:58:56Z

Che: /* History */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T17:58:31Z

Che: /* History */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-15T17:57:18Z

Che: /* Definition */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-11T02:36:22Z

Che: /* References */

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==Definition==

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
http://en.wikipedia.org/wiki/Design_by_contract
 
http://www.cs.unc.edu/~stotts/204/contract.html
 
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-11T02:36:03Z

Che:

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==Definition==

==Benifit==

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=
http://en.wikipedia.org/wiki/Design_by_contract
http://www.cs.unc.edu/~stotts/204/contract.html
http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-11T02:32:08Z

Che: /* Benifit= */

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-11T02:31:45Z

Che:

<big>'''Programming by Contract'''</big>

__TOC__

=Common programming errors=

=Programming by contract=

==Definition==

==Benifit===

==How does it work with inheritance?==

==Examples==

===Example 1===

===Example 2===

===Example 3===

=Summary=

=References=

CSC/ECE 517 Fall 2011/ch18 6a sc

2011-11-08T23:39:04Z

Che: Created page with "<big>'''Programming by Contract'''</big> __TOC__ =What is Programming by Contract= =Section 1= ==Example== =Section 2= ==Example== =Summary= =References="

<big>'''Programming by Contract'''</big>

__TOC__

=What is Programming by Contract=
=Section 1=
==Example==
=Section 2=
==Example==
=Summary=
=References=

CSC/ECE 517 Fall 2011/ch2 2c ac

2011-09-30T05:11:40Z

Che: /* Comparing Ruby mixins to Java interfaces */

__TOC__

=Ruby mixins versus Java interfaces=

To inherit from multiple sources Ruby uses mixins while Java uses interfaces.
This article explains both mechanisms, finds similarities and highlights differences between the two.
Some code samples show the practical use of both mechanisms.
The article also tries to remark situations where the use of one mechanism would be more appropriate than the other.

= Ruby [http://en.wikipedia.org/wiki/Mixin mixins] =
In Ruby a mixin happens when a <tt>module</tt> is included/mixed into a class or into another module.

A <tt>module</tt> is "a way of grouping together" different elements like class/instance methods, classes, instance variables and constants.(Thomas [3] page 76)

<pre>
# module Introspect defines a method named 'kind'
module Introspect
def kind
puts "#{self.class.name}"
end
end
</pre>
A module cannot be instantiated but it can be included/mixed into another class
<pre>
# The Animal and the Car classes include/mix in the module Introspect
class Animal
include Introspect
end

class Car
include Introspect
end
</pre>
The class that includes a module inherits anything that the module defines.
<pre>
d = Animal.new
c = Car.new

# the method 'kind' is inherited from the Introspect module
puts d.kind
puts c.kind

# outputs
Animal
Car
</pre>

Notice that the code in the module has access to variables of the host class. In this sample the ''kind'' method defined in the ''Introspect'' module accesses the <tt>self</tt> variable of the host class (either ''Animal'' or ''Car'').

=Java [http://download.oracle.com/javase/tutorial/java/concepts/interface.html interfaces]=
In its most common form, an interface is a group of related methods with empty bodies.
A bicycle's behavior, if specified as an interface, might appear as follows:
<pre>
interface Bicycle {

void changeGear(int newValue);

void speedUp(int increment);

void applyBrakes(int decrement);
}
</pre>
To implement this interface, the name of your class would change (to a particular brand of bicycle, for example, such as ACMEBicycle), and you'd use the <tt>implements</tt> keyword in the class declaration:
<pre>
class ACMEBicycle implements Bicycle {

void changeGear(int newValue){
// method implementation
}

void speedUp(int increment){
// method implementation
}

void applyBrakes(int decrement){
// method implementation
}

}</pre>

=Comparing Ruby mixins to Java interfaces=
These two diagrams from [http://www.slideshare.net/mbowler/ruby-for-java-programmers Ruby For Java Programmers] illustrates how inheritance is done by Ruby mixins and Java interfaces.
{|
|-
!Ruby Mixins
!Java Interfaces
|-
|[[File:rubymixin.png|200px]]
|[[File:javainheritance.png|300px]]
|}

Now let's look at some of the differences and similarities between Ruby mixins and Java interfaces.
==Implementation Inheritance==
In Ruby, a class that includes a module inherits the implementation of the methods defined in the module as well as the instance variables defined in the module.

In Java, a class that implements an interface inherits the signatures of the methods defined in the interface but it must provide with the implementation of the methods itself.

In the Ruby sample the host class inherits from the ''Introspect'' module the implementation of the ''kind'' method and therefore it can call the method right away.

The ability to call the inherited methods right away is good for rapid prototyping, but in Ruby, one should be aware that the <tt>include</tt> “statement makes a reference to a module. If multiple classes include that module they’ll all point to the same thing. If you change the definition of a method within that module, even while your program is running, all classes that include the module will exhibit the new behavior.” (Thomas [3] page 79)

Bloch reminds us that this is one of the risks of ''implementation inheritance'': for its proper function, the host class may depend on the implementation of the included module. If the implementation of the included module changes the host class may brake. (Bloch [1] page 81)

Another risk associated to ''implementation inheritance'' in Ruby is that "mixed-in module's instance variables can clash with the ones of the host class or with the ones of other mixins."(Thomas [3] page 82)

For example the following module adds the instance variable ''@observer_list''

<pre>
module Observable
def observers
@observer_list ||= []
end
def add_observer(obj)
observer << obj
end
def notify_observers
observers.each {|o| o.update}
end
end
</pre>
but a class that includes the module could also use an instance variable named ''@observer_list''
<pre>
class TelescopeScheduler
# other classes can register to get notifications when the schedule changes
include Observable
def initialize
@observer_list = [] # people with telescope time
end
def add_viewer(viewer)
@observer_list << viewer
end
end
</pre>
If this happens, Thomas states that, at runtime, the TelescopeScheduler could malfunction in ways difficult to diagnose. (Thomas [3] page 82)

With Java interfaces this problem cannot happen because there's no implementation inheritance: Any field you declare in an interface is automatically public static and final, in other words a constant and not an instance variable that can be inherited.

==Separation of interface and implementation==
Java interfaces ensure the separation of interface and implementation by requiring the implementing classes to implement all the methods inherited from the interfaces.
Ruby does not enforce this separation in mixins.

For example we have a <tt>Shape</tt> interface, and a <tt>Circle</tt> class that implements <tt>Shape</tt>

<pre>
package interfaces;

public interface Shape {
public void draw();
}

package classes;

import interfaces.Shape;

public class Circle implements Shape{
public void draw()
{
System.out.println("This method draws a circle");
}
}
</pre>

If the Circle class does not provide a <tt>draw</tt> method, the class will not compile.

However, in Ruby, an interface can be simulated but a class does not require to override the inherited methods.

<pre>
module Shape
def draw
raise NoMethodError, "draw method is not defined for Shape"
end
end

class Circle
include Shape
end

puts Circle.new.draw

=>shape.rb:3:in `draw': draw method is not defined for Shape (NoMethodError)
</pre>

==Method name collision handling==
Method names collisions in Java interfaces are eliminated at compile time.

Because of the unbound polymorphism nature, the return type of Ruby method is determined at run time. This allows a class inherits from two modules that include same method call with different return types.

In Java, a class cannot inherit from two interfaces that include same method with different return type, due to the name conflict.
For example,
<pre>
public interface I1 {
public void method1();
}
public interface I2 {
public int method1();
}

package classes;
import interfaces.I1;
import interfaces.I2;

public class Mul_inherit implements I1, I2{
...
}
</pre>

The Mul_inherit class will give error since there are no ways to satisfy both method1 signatures from I1 and I2.

But with Mixin this example is allowed since
<ul>
1. A method always returns a value (nil if nothing is defined).
</ul><ul>
2. The type of return object is determined at runtime.
</ul>
<pre>
module M1
def method1
#this method returns nothing"
end
end

module M2
def method1
"returns a string"
end
end

class Myclass
include M1
include M2
end

puts Myclass.new.method1

=>returns a string
</pre>

In Ruby the latest method definition always overloads the previous one, therefore, the name collision needs to be handled more carefully.

To avoid name clashes at the origin each module could prefix the name of a method with the name of the module so that the two modules in the previous example could become

<pre>
module M1
def M1method1
"this is M1method1"
end
end

module M2
def M2method1
"this is M2method1"
end
end

class Myclass
include M1
include M2
end

puts Myclass.new.M1method1
puts Myclass.new.M2method1

=>this is M1method1
=>this is M2method1
</pre>

== Ruby mixins vs. Java interfaces feature comparison ==
Now lets look at some features Ruby mixin provides and compare it with Java interface.

{| class="wikitable" style="margin: 1em auto 1em auto;"
|-
! scope="col" | Features
! scope="col" | Ruby Mixins
! scope="col" | Java Interfaces
|-
! scope="row" | Add functionality/behavior to a class
| Yes. When a Ruby module gets mixed in a Ruby class, the class receives the implementation (behavior) of the methods defined in the module. || No. A Java interface "can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated—they can only be implemented by classes or extended by other interfaces." (Java Interface)
|-
! scope="row" | Favor composition over inheritance
| Yes. The class that includes a module establishes a "use-a" relationship with the module. This is composition. || No. The class that implements an interface establishes a "is-a" relationship with the interface. This is inheritance.
|-
! scope="row" | The code of the mixin/interface interacts with the code of the class that includes/implements it
| Yes. A mixed-in module can implement methods in terms of the host's class methods. See the Enumerable example.|| No. An interface provides a set of method signatures that the host class must implement. An interface provides no implementation of methods.
|}

= Examples=
We are going to compare mixin and interface implementations by looking at some code examples.
== Comparable==
<tt>Comparable</tt> provides a set of operations that can be used to compare two objects.

=== In Ruby===
If a Ruby class wants to use <tt>Comparable</tt> functions, it needs to define a method called <=> (sometimes called “rocket”). Ones the rocket function is defined, we get a lot of comparison functions for free, such as <tt><, >, <=, >=, == </tt>and the method <tt>between</tt>.

Suppose we have a <tt>Rectangle</tt> class.

<pre>
class Rectangle
attr_reader :x,:y
def initialize(x,y)
@x,@y=x,y
end
end
</pre>

Now we want to compare the area of two rectangles. We can do so by include the <tt>Comparable</tt> mixin.

<pre>
class Rectangle
include Comparable
def area
x*y
end
def <=>(other)
self.area<=>other.area
end
end
</pre>

The <=> function uses <tt>Comparable</tt> mixin of <tt>Fixnum</tt> class to compare the area of two rectangles. We can call the <tt>Comparable</tt> methods on <tt>Rectangle</tt> objects.

<pre>
r1 = Rectangle.new(3,4)
r2 = Rectangle.new(4,5)
puts r1.area
if r1 < r2
puts "The area of Rectangle 1 is smaller than Rectangle 2"
else if r1 > r2
puts "The area of Rectangle 1 is larger than Rectangle 2"
else
puts "The area of Rectangle 1 equals to Rectangle 2"
end
end

=>12
=>The area of Rectangle 1 is smaller than Rectangle 2
</pre>

=== In Java===
Java provides <tt>Comparable</tt> interface. A Java class implements <tt>Comparable</tt> interface need to define <tt>compareTo</tt> method.

For the same <tt>Rectangle</tt> class example, we need to define <tt>compareTo</tt> method, and define each of the <tt><=></tt> operators within the method.

<pre>
public class Rectangle implements Comparable {

private int x,y;

public Rectangle(int width, int length)
{
x=width;
y=length;
}

public int area()
{
return x*y;
}
public int compareTo(Object otherRectangle)
{
/*
* If passed object is of type other than Rectangle, throw ClassCastException
*/
if(!(otherRectangle instanceof Rectangle)){
throw new ClassCastException("Invalid object");
}
/*
* If left operand less than right operand return -1
* If left operand greater than right operand return 1
* If left operand equals to right operand return 0
*/
int otherArea=((Rectangle)otherRectangle).area();
if (this.area() < otherArea)
return -1;
else if (this.area() > otherArea)
return 1;
else
return 0;
}
}
</pre>

<tt>compareTo</tt> function is then used on <tt>Rectangle</tt> object when comparing two Rectangle objects.

<pre>
public class CompareRectangle {
public void main(String args[]){

Rectangle r1=new Rectangle(3,4);
Rectangle r2=new Rectangle(4,5);

if (r1.compareTo(r2) < 0)
System.out.println("The area of Rectangle 1 is smaller than Rectangle 2");
if (r1.compareTo(r2) > 0)
System.out.println("The area of Rectangle 1 is larger than Rectangle 2");
if (r1.compareTo(r2)==0)
System.out.println("The area of Rectangle 1 equals to Rectangle 2");

}
}
</pre>

== Singleton==
The <tt>Singleton</tt> design pattern ensures that only one instance of a particular class may be created for the lifetime of a program.

=== In Ruby ===
The <tt>singleton</tt> library contains the <tt>Singleton</tt> module that if mixed into a class will make the class a singleton.
The <tt>Singleton</tt> module makes the mixee <tt>new</tt> method private and replaces it with a method called <tt>instance</tt> that when called returns a singleton instance of the mixee.

You do not have to code the singleton functionality inside each class that needs to be a singleton.

<pre>
require 'singleton'

class Klass
include Singleton
end

a,b = Klass.instance, Klass.instance
=> [#<Klass:0x007fa7a28798e8>, #<Klass:0x007fa7a28798e8>]

a == b
=> true

Klass.new
NoMethodError: private method `new' called for Klass:Class
</pre>

=== In Java ===
Each class that needs to be a singleton must implement the singleton functionality itself such as in the following example.

<pre>
public class Singleton {
private static final Singleton instance = new Singleton();

/**
Private constructor prevents instantiation from other classes
**/
private Singleton() {
}

public static Singleton getInstance() {
return instance;
}
}
</pre>

== Enumerable==
The <tt>Enumerable</tt> pattern is used to describe a set of fix constants.
=== In Ruby===
<tt>Enumerable</tt> is a standard mixin in Ruby that can be included in any class. A class wants to use <tt>Enumerable</tt> functions need to define <tt>each</tt> method.

Consider a class takes a string and change the words to uppercase.

<pre>
class WordToUpper
include Enumerable
attr_reader :string
def initialize(string)
@string=string
end
def each
@string.upcase.scan(/\w/) do |upper|
yield upper
end
end
def to_s
self.each{|a| puts a}
end
end
</pre>

Now that <tt>each</tt> method is defined we can use <tt>inject</tt> method from <tt>Enumerable</tt> mixin.

<pre>
puts WordToUpper.new("Rudolph is a Ring Deer!").inject{|v,n| v+n}

=>RUDOLPHISARINGDEER
</pre>

=== In Java ===
In Java there is no interface comparable to the <tt>Enumerable</tt> mixin in Ruby defined. Java can simulate the use of <tt>Enumerable</tt> by using <tt>Iterator</tt> class. However, it is not as convenient as have a <tt>Enumerable</tt> interface.

<pre>
import java.util.*;

public class EnumerableExample {
public static void main(String args[])
{
//removal of items requires an explicit iterator :
Collection<String> words = new ArrayList<String>();
words.add("Rudolph");
words.add("is");
words.add("a");
words.add("red");
words.add("nose");
words.add("ring");
words.add("deer");
for(Iterator<String> iter = words.iterator(); iter.hasNext();){
if (iter.next().length() == 4){
iter.remove();
}
}
}
}
</pre>

In this example, we removed all strings with length of 4 in the <tt>Collection</tt>.

== DataMapper ==
Martin Fowler describes the Data Mapper design pattern as "a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema. (The database schema is always ignorant of the objects that use it.)"(Data Mapper)

=== In Ruby ===
The DataMapper Ruby library was originally developed to address perceived shortcomings in Ruby on Rails' ActiveRecord library. For example DataMapper lets you avoid writing raw query fragments yourself. It allows you to write

<pre>Zoo.all(:name => 'Dallas')</pre>

instead of

<pre>Zoo.find(:all, :conditions => [ 'name = ?', 'Dallas' ])</pre>

=== In Java ===

The [http://code.google.com/p/mybatis/ mybatis SQL Mapping Framework] implements the Data Mapper design pattern.
Its setup and use though seem more complicated than the DataMapper Ruby library.

= Mixins in Java =
Java does not support mixins natively.

Different approaches try to reproduce the mixin feature in Java.

One example is the [http://cglib.sourceforge.net/ cgilb] Java library.
It provides the [http://cglib.sourceforge.net/apidocs/index.html Mixin] class that allows multiple objects to be combined into a single larger object at run time. The methods in the generated object simply call the original methods in the underlying "delegate" objects.

A similar result is achieved at compile time by this [http://code.google.com/p/javadude/wiki/AnnotationsMixinExample Java annotations processor]. Let's say for example that you want to combine/mix the functionality of three classes into one class. You can write a Java annotation that declares which classes you want to mix, then you pass this annotation to the annotation processor and you get the source code of a class that combines all the three behaviors.

Another approach is to implement the [http://en.wikipedia.org/wiki/Decorator_pattern Decorator] design pattern. In this case the new behavior is added not statically to classes at compile time but to specific objects/instances at run time.
=Conclusion=
In comparison with Java interface, Ruby mixin provides more flexibility and functionality. Ruby mixin can include behavior to a class. It makes mix and match of several classes easy. It also includes many standard mixins such as Singleton, Comparable, Enumerable and Datamapper, these standard modules make these design patterns easy to use and inherit functions by new objects. While Ruby mixin might seem more powerful than Java interface, Java interface still have its advantage over Ruby mixin in some cases. Java interface handles separation of interface and implementation better, it also handles name collision more strictly than Ruby mixin. Furthermore, when Ruby class includes a module, it gets a reference of the module, which increases coupling between the class and the included module. If the included module changes during runtime the class might result in some unexpected behavior.

=References=

1. Joshua Bloch, "Effective Java". Second Edition. May 2008, Prentice Hall.

2. [http://www.slideshare.net/mbowler/ruby-for-java-programmers Ruby For Java Programmers] by Mike Bowler.

3. Dave Thomas, Chad Fowler, Andy Hunt, "Programming Ruby 1.9: The Pragmatic Programmers' Guide (Facets of Ruby Series)". Third Edition. April 2009, Pragmatic Bookshelf.

4. [http://download.oracle.com/javase/tutorial/java/IandI/createinterface.html Java Interface] From oracle.com, the Java Tutorials.

5. [http://en.wikipedia.org/wiki/Mixin Mixin] From Wikipedia, the free encyclopedia.

6. [http://martinfowler.com/eaaCatalog/dataMapper.html Data Mapper Design Pattern] From Martin Fowler.

7. [http://datamapper.org/ Data Mapper in Ruby] From DataMapper, Ruby Object Relational Mapper.

8. [http://code.google.com/p/mybatis/ Data Mapper in Java] From mybatis - SQL mapping framwork for Java.

9. [http://cglib.sourceforge.net/ cgilb] From Code Generation Library, [http://cglib.sourceforge.net sourceforge.net].

10. [http://code.google.com/p/javadude/wiki/AnnotationsMixinExample Java annotations processor] From AnnotationsMixinExample, JavaDude OpenSource Projects.

11. [http://en.wikipedia.org/wiki/Decorator_pattern Decorator pattern] From Wikipedia, the free encyclopedia.