David evans http www cs virginia edu evans
This presentation is the property of its rightful owner.
Sponsored Links
1 / 26

David Evans cs.virginia/~evans PowerPoint PPT Presentation


  • 77 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

David Evans cs.virginia/~evans

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


David evans http www cs virginia edu evans

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

When you climb up the tree, the Grizzly climbs up after you. The Black Bear knocks down the tree. (Which is the behavioral subtype?)

David Evans

http://www.cs.virginia.edu/~evans

BlackBear

GrizzlyBear

CS655: Programming Languages

University of Virginia

Computer Science


David evans cs virginia evans

Menu

  • Wrap-up “What is Object-Oriented Programming?”

  • Behavioral Notion of Subtyping

CS 655: Lecture 17


Last time

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)

CS 655: Lecture 17


Implementation reuse subclassing inheritance

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)

CS 655: Lecture 17


Language principle getting defaults right matters

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

CS 655: Lecture 17


A type and class hierarchy

A Type and Class Hierarchy

Shape

Quadrangle

Equilateral

Triangle

Parallelogram

EquilateralTriangle

Rhombus

Rectangle

Square

CS 655: Lecture 17


Add an attribute

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

CS 655: Lecture 17


Add is equilateral

Add is_equilateral

bool Shape::is_equilateral () {

return false;

}

bool Equilateral::is_equilateral () {

return true;

}

CS 655: Lecture 17


Is a rhombus equilateral

Is a Rhombus equilateral?

Shape

is_equilateral () { return false; }

is_equilateral () {

return true;

}

Quadrangle

Equilateral

Parallelogram

Multiple inheritance can be tricky!

Rhombus

is_equilateral?

CS 655: Lecture 17


Solutions

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)

CS 655: Lecture 17


Smalltalk design principles

Smalltalk Design Principles

Personal 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.

CS 655: Lecture 17


Smalltalk design principles 2

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.

CS 655: Lecture 17


Stroustrup s conclusions

Stroustrup’s Conclusions

“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.”

CS 655: Lecture 17


My conclusions

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.

, ST

A

E :S

[subsumption]

A

E : T

CS 655: Lecture 17


Analogies

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

CS 655: Lecture 17


How do we know if s t is safe

How do we know if STis safe?


What does it mean for s t to be safe

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.

  • 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.

Too Strong

CS 655: Lecture 17


L w s subtype requirement

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.

CS 655: Lecture 17


Type specification

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

CS 655: Lecture 17


Two tiered specification

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?

CS 655: Lecture 17


Lsl specification

LSL Specification

Bag (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)

CS 655: Lecture 17


Subtype definition s t

Subtype Definition (ST)

  • 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.

  • Subtypes preserve supertype properties

    • Invariant of S implies invariant of T.

    • Constraint of S implies constraint of T.

CS 655: Lecture 17


Subtype condition 1 signature rule

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

CS 655: Lecture 17


Subtype condition 1 methods rule

Subtype Condition 1: Methods Rule

  • 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]

“contravariance – subtype is weaker”

“covariance – subtype is stronger”

CS 655: Lecture 17


Subtype relation 2 preserves supertype properties

Subtype Relation 2: Preserves supertype Properties

  • 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”

CS 655: Lecture 17


Charge

Charge

  • Don’t stop working on your projects just because you turned in your proposal...

  • Next time: pragmatic aspects of OO languages - comparison of Sather, Eiffel, Java and C++

CS 655: Lecture 17


  • Login