Transcript Slides

Killer
Lecture 12:
Subtyping
Rules
Bear
Climber
KillingBear
BlackBear
GrizzlyBear
CS201j: Engineering Software
University of Virginia
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?)
David Evans
http://www.cs.virginia.edu/~evans
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
15 October 2002
CS 201J Fall 2002
2
public class Bear {
public Bear () { }
Subtyping Example
abstract public boolean chaseHuman (Human h);
public void eatHuman (Human h) {
if (chaseHuman (h)) say (“Yum Yum!”);
}
}
public void say (String s) {
System.err.println (“Bear says: ” + s);
BlackBear b = new BlackBear ();
b.eatHuman (h);
15 October 2002
public class BlackBear extends Bear {
public boolean chaseHuman (Human h) {
// follow h and climb the tree
return true;
}
public void say (String s) {
System.err.println (“BlackBear says: ” + s);
}
CS 201J Fall 2002
3
How do we know if
saying B is a subtype of A
is safe?
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.
15 October 2002
CS 201J Fall 2002
5
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);
}
15 October 2002
CS 201J Fall 2002
6
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
15 October 2002
CS 201J Fall 2002
7
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
15 October 2002
CS 201J Fall 2002
8
Signature Examples
public class Object {
public boolean equals (Object o) ;
}
public class String extends Object {
public boolean equals (Object o) ;
}
15 October 2002
CS 201J Fall 2002
9
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.
publicCell
ConwayCell
()
public
choose ()choose
;
}
Return type must be a supertype.
15 October 2002
CS 201J Fall 2002
10
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.
15 October 2002
CS 201J Fall 2002
11
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);
}
15 October 2002
CS 201J Fall 2002
12
Subtype Condition 2: Methods Rule
• Precondition of the subtype method
must be weaker than the precondition of
the supertype method.
mA.pre  mB.pre
• Postcondition of the subtype method
must be stronger than the postcondition
of the supertype method.
mB.post  mA.post
15 October 2002
CS 201J Fall 2002
13
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
}
15 October 2002
CS 201J Fall 2002
stronger! The callsite might
not satisfy it.
14
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
}
15 October 2002
CS 201J Fall 2002
15
Subtype Condition 3: Properties
Subtypes must preserve all properties
described in the overview specification
of the supertype.
15 October 2002
CS 201J Fall 2002
16
Substitution Principle
Is this the only way?
15 October 2002
CS 201J Fall 2002
17
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
15 October 2002
CS 201J Fall 2002
18
Eiffel’s Rules
(Described in Bertrand Meyer paper out today)
15 October 2002
CS 201J Fall 2002
19
Eiffel Rules
The types of the parameters in the
subtype method may be subtypes
of the supertype parameters.
Skier
set_roommate (Skier)
How can Girl override set_roomate?
set_roommate (Girl g)
set_roommate (Boy b)
Boy
Girl
Opposite of substitution principle!
15 October 2002
CS 201J Fall 2002
20
Can’t Get Up?
Skier
set_roommate (Skier)
Boy
15 October 2002
s: skier; g: girl; b: boy;
s := g;
...
s.set_roommate (b);
Girl
set_roomate (Girl)
CS 201J Fall 2002
21
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.
15 October 2002
CS 201J Fall 2002
22
PS5
• First part (due Thursday Oct 24):
– 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 Halloween):
– Implement your distributed simulation
15 October 2002
CS 201J Fall 2002
23
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
15 October 2002
CS 201J Fall 2002
24