CSC/ECE 517 Fall 2009/wiki3 20 i7: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 28: Line 28:


==Preconditions==
==Preconditions==
When dealing with Liskov substitution, preconditions cannot be strengthened.  This is fairly intuitive, in other words, the subtype cannot require anymore preconditions than the parent.  This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently.  There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation.  Take for instance this example in Java which illustrates this point.
When dealing with Liskov substitution, preconditions cannot be strengthened.  Intuitively, the subtype cannot require anymore preconditions than the parent.  This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently.  There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation.  Take for instance this example in Java which illustrates this point.


<pre>
<pre>
Line 37: Line 37:


==Postconditions==
==Postconditions==
Postconditions cannot be weakened.  <Explain in english>
When dealing with Liskov substitution, postconditions cannot be weakened.  Intuitively, the subtype cannot require any less postconditions than the parent. <CONTINUE HERE>


==Invariants==
==Invariants==

Revision as of 09:18, 18 November 2009

Liskov substitution principle

The Liskov substitution principle was introduced by Barbara Liskov in 1987 and is concerned with subtype contractual correctness. Based on a paper from 1994 the principle states, "Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.". This means that for every parent type T, subtype S should be able to be substituted in for it and the behavior of the program should remain exactly the same. The following example in Java illustrates the principle.


public class MyClass {
    private final List<String> list;

    public MyClass(List<String> list) {
        this.list = list;
    }
    ....
}

public class TestRunner {
    public static void main ( String[] args ) {
        // If the List type follows Liskov substitution...
        List<String> arrayList = new ArrayList<String>();
        List<String> linkedList = new LinkedList<String>();

        // ...I should be able to use any subtype of List to create a new MyClass and observe identical behavior!
        MyClass this = new MyClass(arrayList);
        MyClass works = new MyClass(linkedList);
    }
}

Preconditions

When dealing with Liskov substitution, preconditions cannot be strengthened. Intuitively, the subtype cannot require anymore preconditions than the parent. This makes sense because if the subtype required more than the parent, then the subtype would not be able to be effectively substituted in for the parent transparently. There would need to be more preconditions satisfied after substituting in the subtype in this hypothetical situation. Take for instance this example in Java which illustrates this point.


Example code here

Postconditions

When dealing with Liskov substitution, postconditions cannot be weakened. Intuitively, the subtype cannot require any less postconditions than the parent. <CONTINUE HERE>

Invariants

Invariants must be preserved. <Explain in english>

References