Killer Lecture 13 Subtyping Rules Bear Climber Killing

Killer Lecture 13: Subtyping Rules Bear Climber Killing. Bear Black. Bear Grizzly. Bear CS 201 j: Engineering Software University Virginia 16 Octoberof 2003 Computer Science What’s the difference between a Black Bear and a Grizzly Bear? When you climb up the tree, the Black Bear climbs up after you. The Grizzly Bear knocks down the tree. (Which is the behavioral subtype? ) CS 201 J Fall 2003 David Evans http: //www. cs. virginia. edu/evans

Announcements • Exam 1 out at end of class today – Open book, open notes – Work alone, don’t use Java compiler – If I have any reasons to suspect the honor policy is not followed on this exam, you will have a closed book final during Exam week • No section meetings tomorrow 16 October 2003 CS 201 J Fall 2003 2

Recap • If B is a subtype of A, everywhere the code expects an A, a B can be used instead • To implement a subtype, it is often useful to use the implementation of its supertype class B extends A B is a subtype of A B inherits from A class C implements F C is a subtype of F 16 October 2003 CS 201 J Fall 2003 3

public class Bear { public Bear () { } Subtyping Example abstract public boolean chase. Human (Human h); public void eat. Human (Human h) { if (chase. Human (h)) say (“Yum Yum!”); } } public void say (String s) { System. err. println (“Bear says: ” + s); Black. Bear b = new Black. Bear (); b. eat. Human (h); 16 October 2003 public class Black. Bear extends Bear { public boolean chase. Human (Human h) { // follow h and climb the tree return true; } public void say (String s) { System. err. println (“Black. Bear says: ” + s); } CS 201 J Fall 2003 4

Overloading and Overriding • Overriding: replacing a supertype’s method in a subtype – Dynamic dispatch finds method of actual type • Overloading: providing two methods with the same name but different parameter types – Statically select most specific matching method of apparent type 16 October 2003 CS 201 J Fall 2003 5

Overloading Example public class Overloaded extends Object { public int try. Me (Object o) { return 17; } public int try. Me (String s) { return 23; } } public boolean equals (String s) { return true; public boolean equals (Object) } is inherited from Object 16 October 2003 CS 201 J Fall 2003 6

public class Overloaded { public int try. Me (Object o) { return 17; } public int try. Me (String s) { return 23; static public void main (String args[]) { } Overloaded over = new Overloaded (); public boolean equals (String s) { System. err. println (over. try. Me (over)); return true; System. err. println (over. try. Me (new String ("test"))); } } Overloading Object obj = new String ("test"); System. err. println (over. try. Me (obj)); System. err. println (over. equals (new String ("test"))); System. err. println (over. equals (obj)); Object obj 2 = over; System. err. println (obj 2. equals (new String ("test"))); } 16 October 2003 CS 201 J Fall 2003 17 23 17 true false 7

Overkill • Overloading and overriding together can be overwhelming! • Avoid overloading whenever possible: names are cheap and plentiful • One place you can’t easily avoid it: constructors (they all have to have the same name) 16 October 2003 CS 201 J Fall 2003 8

How do we know if saying B is a subtype of A is safe? 16 October 2003 CS 201 J Fall 2003

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. 16 October 2003 CS 201 J Fall 2003 10

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); } 16 October 2003 CS 201 J Fall 2003 11

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 16 October 2003 CS 201 J Fall 2003 12

Signature Rule class A { public RA m (PA p) ; } class B extends A { public RB m (PB p) ; } RB must be a subtype of RA: RB <= RA PB must be a supertype of PA: PB >= PA covariant for results, contravariant for parameters 16 October 2003 CS 201 J Fall 2003 13

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

Signature Examples public class Cell. Set { // A set of Cell’s. public Cell choose () throws No. Such. Element. Exception ; } public class Conway. Cell. Set extends Cell. Set { // A set of Conway. Cell (<= Cell) objects. public. Cell Conway. Cell () public choose ()choose ; } Return type must be a subtype of Cell. 16 October 2003 CS 201 J Fall 2003 15

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. 16 October 2003 CS 201 J Fall 2003 16

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) { // REQUIRES: a is initialized // EFFECTS: returns a. value * x. value return a. m (x); } 16 October 2003 CS 201 J Fall 2003 17

Subtype Condition 2: Methods Rule • 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 16 October 2003 CS 201 J Fall 2003 18

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 } 16 October 2003 CS 201 J Fall 2003 stronger! The callsite might not satisfy it. 19

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 } 16 October 2003 CS 201 J Fall 2003 20

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

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

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

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

Subtyping Rules class A { public RA m (PA p) ; } … (in client code) Mystery. Type 1 mt 1; Mystery. Type 2 mt 2; Mystery. Type 3 mt 3; … mt 1 = mt 2. m (mt 3); If A is Mystery. Type 2, what do we know about RA and PA? RA must be a subtype of Mystery. Type 1: RA <= Mystery. Type 1 Mystery. Type 3 must be a subtype of PA: PA >= Mystery. Type 3 16 October 2003 CS 201 J Fall 2003 25

Subtyping Rules … (in client code) class A { Mystery. Type 1 mt 1; public RA m (PA p) ; Mystery. Type 2 mt 2; } Mystery. Type 3 mt 3; class B extends A { … public RB m (PB a); mt 1 = mt 2. m (mt 3); } If B <= A, what do we know about RB and PB? RB must be a subtype of RA: RB <= RA PA must be a subtype of PB: PB >= PA 16 October 2003 CS 201 J Fall 2003 26

Substitution Principle … (in client code) class A { Mystery. Type 1 mt 1; public RA m (PA p) ; Mystery. Type 2 mt 2; } Mystery. Type 3 mt 3; class B extends A { … public RB m (PB a); mt 1 = mt 2. m (mt 3); } Substitution Principle: Parameters PB >= PA Preconditions pre_A pre_B Result Postconditions 16 October 2003 RB <= RA post_B post_A CS 201 J Fall 2003 27

Substitution Principle Is this the only way? No…Tuesday we’ll look at an alternative. 16 October 2003 CS 201 J Fall 2003 28