Upload
palmer-rios
View
31
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Lecture 17: Inheritance & Behavioral Subtyping (when is S T safe?). Killer. Bear. What’s the difference between a Black Bear and a Grizzly Bear?. Climber. KillingBear. - PowerPoint PPT Presentation
Citation preview
David Evanshttp://www.cs.virginia.edu/~evans
CS655: Programming LanguagesUniversity of VirginiaComputer Science
Lecture 17: Inheritance & Behavioral
Subtyping (when is S T safe?)
What’s the difference between a Black Bear and a Grizzly Bear?
When you climb up the tree, the Grizzly climbs up after you. The Black Bear knocks down the tree. (Which is the behavioral subtype?)
Killer
BlackBear GrizzlyBear
Climber
Bear
KillingBear
27 March 2001 CS 655: Lecture 17 2
Menu
• Wrap-up “What is Object-Oriented Programming?”
• Behavioral Notion of Subtyping
27 March 2001 CS 655: Lecture 17 3
Last time
• Defined subtyping as subsumption
• Showed typing judgments that support subtype polymorphism
• Some language features that support subtype polymorphism:– Dynamic type-directed method dispatch– Subclassing (Implementation inheritance)
27 March 2001 CS 655: Lecture 17 4
Implementation Reuse:Subclassing, Inheritance
• Use implementation of one type to implement another type
• Often use implementation of supertype to implement subtype
• Commonly used OO languages confuse issue by combining subtyping and inheritance:– Eiffel – cannot separate – Java – cannot separate, can use interfaces for
subtyping only– C++ - can use implementation inheritance without
subtyping (private, protected inheritance)
27 March 2001 CS 655: Lecture 17 5
Language Principle:Getting Defaults Right Matters
• Shouldn’t require extra work to hide things, should require extra work to expose them (forgetting something should be safer)
• Possible Examples:– Algol60: call-by-value requires extra work (should
have been call-by-name)– Java: preventing overriding requires extra work
(final) / opposite of C++– C++: preventing subtyping requires extra work
(public inheritance is default, need private to reuse implementation without subtyping)
– Java access: default is package protected, need private to hide variables and methods
27 March 2001 CS 655: Lecture 17 6
A Type and Class HierarchyShape
Quadrangle Triangle
Rectangle
Parallelogram
Rhombus
Square
Equilateral
EquilateralTriangle
27 March 2001 CS 655: Lecture 17 7
Add an attribute
• Shapes should have a color and set_color method
• Change Shape, Quadrangle, Parallelogram, Triangle, Equilateral, EquilateralTriangle, Rhombus, Rectangle, Square, etc.
• Change Shape, others inherit new attribute and method automatically
27 March 2001 CS 655: Lecture 17 8
Add is_equilateral
bool Shape::is_equilateral () {
return false;
}
bool Equilateral::is_equilateral () {
return true;
}
27 March 2001 CS 655: Lecture 17 9
Is a Rhombus equilateral?
Shape
Quadrangle
Parallelogram
Rhombus
Equilateral
is_equilateral?
is_equilateral () { return false; }
is_equilateral () { return true; }
Multiple inheritance can be tricky!
27 March 2001 CS 655: Lecture 17 10
Solutions• Java, Ada95
– Don’t allow it (Java: interfaces for multiple supertypes, not implementation sharing)
– Pro: Safe and Simple, Con: Limits Reuse
• C++– Allow it, let programmers shoot themselves if
they want
• Eiffel– Explicit renaming or hiding (error if not done)
27 March 2001 CS 655: Lecture 17 11
Smalltalk Design PrinciplesPersonal Mastery: If a system is to serve the
creative spirit, it must be entirely comprehensible to a single individual.
Storage Management: To be truly "object-oriented", a computer system must provide automatic storage management.
Uniform Metaphor: A language should be designed around a powerful metaphor that can be uniformly applied in all areas.
27 March 2001 CS 655: Lecture 17 12
Smalltalk Design Principles 2
Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one.
Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones.
27 March 2001 CS 655: Lecture 17 13
“Object-oriented programming is programming with inheritance. Data abstraction is programming using user-defined types. With few exceptions, object-oriented programming can and ought to be a superset of data abstraction. These techniques need proper support to be effective. Data abstraction primarily needs support in the form of language features and object-oriented programming needs further support from a programming environment. To be general purpose, a language supporting data abstraction or object-oriented programming must enable effective use of traditional hardware.”
Stroustrup’s Conclusions
27 March 2001 CS 655: Lecture 17 14
My Conclusions• Object-Oriented Programming is a state of
mind.• It is difficult to reach that state of mind if your
language doesn’t have a way to declare S T and the type judgment:
• Other language features can help, but we aren’t yet sure what the right ones are: dynamic dispatch, implementation inheritance, mixins, automated delegation, etc.
A E : S , S T A E : T
[subsumption]
27 March 2001 CS 655: Lecture 17 15
Analogies• Structured Programming is a state of
mind.• It is difficult to reach that state of mind if
your language doesn’t have structured control statements (e.g., while, for, if, blocks, procedures)
• Data Abstraction is a state of mind.• It is difficult to reach that state of mind if
your language doesn’t have type checking and mechanisms for restricting access
27 March 2001 CS 655: Lecture 17 17
What does it mean for S T to be safe?• Liskov & Wing: “objects of the subtype ought to
behave the same as those of the supertype as far as anyone or any program using supertype objects can tell.”
• For all functions f, if f behaves correctly when passed a T, f behaves correctly when passed an S.
Too Strong
• For all programs f, if f can be shown to satisfy its specification using the specification of T, then f can be shown to satisfy its specification using the specification of S.
27 March 2001 CS 655: Lecture 17 18
L & W’s Subtype Requirement• Let (x) be a property provable about objects
x of type T. Then (y) should be true for objects y of type S where S is a subtype of T.
• Same meaning?For all programs P, if P can be shown to satisfy its specification using the specification of T, then P can be shown to satisfy its specification using the specification of S.
27 March 2001 CS 655: Lecture 17 19
Type Specification• Description of type’s value space• Type invariant and history properties
(constraint)– How different from rep invariant?
• For each method:– Behavior in terms of pre-conditions and post-
conditions
• No creators – allows subtypes to provide different creators– Need to prove creators establish invariant and
constraint
27 March 2001 CS 655: Lecture 17 20
Two-Tiered Specification
• Separate interface-level specification from sort specification
• Specs in paper are interface-level specifications only:
bag = type
uses BBag (bag for B)
...
get = proc () returns (int)
requires bpre.elems { }
What does this mean?
27 March 2001 CS 655: Lecture 17 21
LSL SpecificationBag (E, C) : trait
introduces { } : C; insert : E, C C; count : E, C Int
asserts
C generated by {}, insert
C partitioned by count
b: C, e, e1, e2: E
count (e, {}) == 0;
count (e1, insert (e2, b)) ==
count (e1, b) + (if e1 = e2 then 1 else 0)
BBag (B) tuple of bound: Int, elems: Bag (Int, B for C)
27 March 2001 CS 655: Lecture 17 22
Subtype Definition (S T)1. Subtype methods preserve the
supertype methods’ behavior:• Signatures have contravariant arguments,
covariant results• Pre-conditions of T imply preconditions of
S; post-conditions of S imply post-conditions of T.
2. Subtypes preserve supertype properties• Invariant of S implies invariant of T.• Constraint of S implies constraint of T.
27 March 2001 CS 655: Lecture 17 23
Subtype Condition 1: Signature Rule
Subtype methods preserve the supertype methods’ behavior:
– Signature:• Contravariance of arguments,
covariance of result (typing rule we saw last time)
• Exceptions by ms are contained in set of exceptions signed by mT
27 March 2001 CS 655: Lecture 17 24
• Methods rule:– Pre-condition
x : s
mT.pre [ A (xpre) / xpre ] mS.pre
Replace every xpre in mT.pre with A (xpre).
Abstraction function, A : s t.
– Post-condition mS.post mT.post [A (xpre) / xpre, A (xpost) / xpost]
Subtype Condition 1: Methods Rule
“contravariance – subtype is weaker”
“covariance – subtype is stronger”
27 March 2001 CS 655: Lecture 17 25
2. Subtypes preserve supertype properties
For all states p and q such that p precedes q, for all x: S:
Invariant Rule IS IT [ A (xp) / xp]
Constraint Rule CS CT [A (xp) / xp, A (xq) / xq ]
“covariance – subtype is stronger”
Subtype Relation 2: Preserves supertype Properties