1. David Evans http://www.cs.virginia.edu/evans CS201j: Engineering Software University of Virginia Computer Science Lecture 14: Substitution Principle

2. How do we know if saying B is a subtype of A is safe?

3. 16 October 2003CS 201J Fall 20033 Substitution Principle If B is a subtype of A, everywhere the code expects an A, a B can be used instead For a function f (A), if f satisfies its specification when passed an object whose actual type is type A, f also satisfies its specification when passed an object whose actual type is B.

4. 16 October 2003CS 201J Fall 20034 What needs to be true? For a function f (a A), if f satisfies its specification when passed an object whose actual type is type A, f also satisfies its specification when passed an object whose actual type is B. public int f (a A, x X) { return a.m (x); }

5. 16 October 2003CS 201J Fall 20035 Subtype Condition 1: Signature Rule We can use a subtype method where a supertype methods is expected: –Subtype must implement all of the supertype methods –Argument types must not be more restrictive –Result type must be at least as restrictive –Subtype method must not throw exceptions that are not subtypes of exceptions thrown by supertype

6. 16 October 2003CS 201J Fall 20036 Signature Rule class A { public R A m (P A p) ; } class B extends A { public R B m (P B p) ; } R B must be a subtype of R A : R B <= R A P B must be a supertype of P A : P B >= P A covariant for results, contravariant for parameters

7. 16 October 2003CS 201J Fall 20037 Signature Examples public class Object { public boolean equals (Object o) ; } public class String extends Object { } public boolean equals (Object o) ;

8. 16 October 2003CS 201J Fall 20038 Signature Examples public class CellSet { // A set of Cell’s. public Cell choose () throws NoSuchElementException ; } public class ConwayCellSet extends CellSet { // A set of ConwayCell (<= Cell) objects. public ConwayCell choose () } Return type can be a subtype (according to substitution principle, not according to Java compiler rules)

9. 16 October 2003CS 201J Fall 20039 Java’s Rule Java compiler is stricter than this: doesn’t allow any variation in types (“novariant”): –Overriding method must have same return and parameter types –Overriding method can throw fewer exceptions.

10. 16 October 2003CS 201J Fall 200310 What needs to be true? For a function f (a A), if f satisfies its specification when passed an object whose actual type is type A, f also satisfies its specification when passed an object whose actual type is B <= A. public int f (a A, x X) { // REQUIRES: a is initialized // EFFECTS: returns a.value * x.value return a.m (x); }

11. 16 October 2003CS 201J Fall 200311 Precondition of the subtype method must be weaker than the precondition of the supertype method. m A.pre  m B.pre Postcondition of the subtype method must be stronger than the postcondition of the supertype method. m B.post  m A.post Subtype Condition 2: Methods Rule

12. 16 October 2003CS 201J Fall 200312 Methods Rule Example public int f (a A, x X) { // REQUIRES: a is initialized // EFFECTS: returns a.value * x.value return a.m (x); } public class A { // An A may be initialized or uninitialized. // An initialized A has an associated int value. public int m (x X) { // REQUIRES: this is initialized } public class B extends A { // A B may be initialized or uninitialized. // A B may be awake or asleep. // An initialized B has an associated int value. public int m (x X) { // REQUIRES: this is initialized and awake } Can’t make the precondition stronger! The callsite might not satisfy it.

13. 16 October 2003CS 201J Fall 200313 Methods Rule Example public int f (a A, x X) { // REQUIRES: a is initialized // EFFECTS: returns a.value * x.value return a.m (x); } public class A { // An A may be initialized or uninitialized. // An initialized A has an associated int value. public int m (x X) { // REQUIRES: this is initialized } public class B extends A { // A B may be initialized or uninitialized. // A B may be awake or asleep. // An initialized B has an associated int value. public int m (x X) { // REQUIRES: nothing }

14. 16 October 2003CS 201J Fall 200314 Methods Rule Example public int f (a A, x X) { // REQUIRES: a is initialized // EFFECTS: returns a.value * x.value return a.m (x); } public class A { // An A may be initialized or uninitialized. // An initialized A has an associated int value. public int m (x X) { // ENSURES: Returns this.value * x.value } public class B extends A { // A B may be initialized or uninitialized. // A B may be awake or asleep. // An initialized B has an associated int value. public int m (x X) { // ENSURES: Returns this.value + x.value. } Postcondition must imply the supertype’s method postcondition.

15. 16 October 2003CS 201J Fall 200315 Methods Rule Example public int f (a A, x X) { // REQUIRES: a is initialized // EFFECTS: returns a.value * x.value return a.m (x); } public class A { // An A may be initialized or uninitialized. // An initialized A has an associated int value. public int m (x X) // MODIFIES: this // ENSURES: Returns this.value * x.value. // Makes this initialized. public class B extends A { // A B may be initialized or uninitialized. // A B may be awake or asleep. // An initialized B has an associated int value. public int m (x X) // MODIFIES: this // ENSURES: Returns this.value * x.value. Makes // this initialized and awake.

16. 16 October 2003CS 201J Fall 200316 Subtypes must preserve all properties described in the overview specification of the supertype. Subtype Condition 3: Properties

17. 16 October 2003CS 201J Fall 200317 Properties Example B <= A If A is an immutable datatype, can B be mutable? If A is a mutable datatype, can B be immutable?

18. 16 October 2003CS 201J Fall 200318 Substitution Principle Summary Signatures: subtype methods must be type correct in supertype callsites: result is a subtype (covariant), parameters are supertypes (contravariant) Methods: subtype postconditions must be stronger than supertype postconditions (covariant); subtype preconditions must be weaker than supertype preconditions (contravariant); Properties: subtype must preserve all properties specified in supertype overview

19. 16 October 2003CS 201J Fall 200319 Substitution Principle …(in client code) MysteryType1 mt1; MysteryType2 mt2; MysteryType3 mt3; …(anything could be here) mt1 = mt2.m (mt3); If the Java compiler is happy with this code, which of these are guaranteed to be true: a.The apparent type of mt2 is MysteryType2 b.At the last statement, the actual type of mt2 is MysteryType2 c.MysteryType2 has a method named m d.The MysteryType2.m method takes a parameter of type MysteryType3 e.The MysteryType2.m method returns a subtype of MysteryType1 f.After the last statement, the actual type of mt1 is MysteryType1

20. 16 October 2003CS 201J Fall 200320 …(in client code) MysteryType1 mt1; MysteryType2 mt2; MysteryType3 mt3; …(anything could be here) mt1 = mt2.m (mt3); If the Java compiler is happy with this code, which of these are guaranteed to be true: a.The apparent type of mt2 is MysteryType2 b.At the last statement, the actual type of mt2 is MysteryType2 c.MysteryType2 has a method named m d.The MysteryType2.m method takes a parameter of type MysteryType3 e.The MysteryType2.m method returns a subtype of MysteryType1 f.After the last statement, the actual type of mt1 is MysteryType1 TRUE: the apparent type is obvious from the declaration. FALSE: we only know the actual type <= MysteryType2 TRUE FALSE: we only know it takes a parameter >= MysteryType3 TRUE: the assignment type checking depends on this FALSE: we only know that the actual type <= MysteryType1

21. 16 October 2003CS 201J Fall 200321 Subtyping Rules class A { public RA m (PA p) ; } …(in client code) MysteryType1 mt1; MysteryType2 mt2; MysteryType3 mt3; … mt1 = mt2.m (mt3); RA must be a subtype of MysteryType1: RA <= MysteryType1 MysteryType3 must be a subtype of PA: PA >= MysteryType3 If A is MysteryType2, what do we know about RA and PA?

22. 16 October 2003CS 201J Fall 200322 Subtyping Rules class A { public RA m (PA p) ; } class B extends A { public RB m (PB a); } …(in client code) MysteryType1 mt1; MysteryType2 mt2; MysteryType3 mt3; … mt1 = mt2.m (mt3); RB must be a subtype of RA: RB <= RA PA must be a subtype of PB:PB >= PA If B <= A, what do we know about RB and PB?

23. 16 October 2003CS 201J Fall 200323 Substitution Principle class A { public RA m (PA p) ; } class B extends A { public RB m (PB a); } …(in client code) MysteryType1 mt1; MysteryType2 mt2; MysteryType3 mt3; … mt1 = mt2.m (mt3); Substitution Principle: Parameters PB >= PA Preconditions pre_A  pre_B Result RB <= RA Postconditions post_B  post_A

24. 16 October 2003CS 201J Fall 200324 Substitution Principle Is this the only way?

25. 16 October 2003CS 201J Fall 200325 Eiffel’s Rules (Described in Bertrand Meyer paper out today)

26. 16 October 2003CS 201J Fall 200326 Eiffel Rules Skier set_roommate (Skier) Boy Girl The types of the parameters in the subtype method may be subtypes of the supertype parameters. How can Girl override set_roomate? set_roommate (Girl g) set_roommate (Boy b) Opposite of substitution principle!

27. 16 October 2003CS 201J Fall 200327 Eiffel and I Can’t Get Up? s: skier; g: girl; b: boy; s := g;... s.set_roommate (b); Skier set_roommate (Skier) Boy Girl set_roomate (Girl)

28. 16 October 2003CS 201J Fall 200328 Meyer’s Excuse Strangely enough, some workers in the field have been advocating a contravariant policy. Here it would mean that if we go for example to class RANKED_GIRL, where the result of roommate is naturally redefined to be of type RANKED_GIRL, we may for the argument of routine share use type GIRL, or rather scaringly, SKIER of the most general kind. One type that is never permitted in this case is RANKED_GIRL! Here is what, under various mathematical excuses, some professors have been promoting. No wonder teenage pregnancies are on the rise.

29. 16 October 2003CS 201J Fall 200329 Substitution Principle / Eiffel class A { public RA m (PA p) ; } class B extends A { public RB m (PB a); } …(in client code) MysteryType1 mt1; MysteryType2 mt2; MysteryType3 mt3; … mt1 = mt2.m (mt3); Substitution PrincipleEiffel Parameters PB >= PAPB <= PA Preconditions pre_A  pre_Bpre_B  pre_A Result RB <= RARB <= RA Postconditions post_B  post_A post_B  post_A

30. 16 October 2003CS 201J Fall 200330 PS5 First part (due Thursday Oct 30): –Questions about subtyping rules Which rules make most sense? Which rules are most useful for real programs? –Exercises to learn about concurrency (Thursday) –Design a distributed simulation of something interesting Second part (due Nov 11): –Implement your distributed simulation

31. 16 October 2003CS 201J Fall 200331 Charge Must it be assumed that because we are engineers beauty is not our concern, and that while we make our constructions robust and durable we do not also strive to make them elegant? Is it not true that the genuine conditions of strength always comply with the secret conditions of harmony? Gustav Eiffel