Chair of Software Engineering ATOT - Lecture 8, 28 April 2003 1 Advanced Topics in Object Technology Bertrand Meyer

ATOT - Lecture 8, 28 April 2003

1

Chair of Software Engineering

Advanced Topics in Object Technology

Bertrand Meyer


2


Lecture 8: Inheritance


3


What is inheritance?

Principle: Describe a new class not from scratch but as extension or specialization of one existing class — or several in the case of MULTIPLE inheritance.

From the module viewpoint: if B inherits from A, all the services of A are potentially available in B (possibly with a different implementation).

From the type viewpoint: inheritance is the ‘‘is-plus-but-except’’ relation. If B inherits from A, whenever an instance of A is required, an instance of B will be acceptable.


4


Terminology

Parent, Heir

Ancestor, Descendant The ancestors of B are B itself

and the ancestors of its parents. Proper ancestor, Proper descendant

Direct instance, Instance The instances of A are the

direct instances of its descendants.

(Other terminology: subclass, superclass, base class)

A

B

feature

feature


5


Example hierarchy

FIGURE*

OPEN_ FIGURE

*CLOSED_ FIGURE

*

SEGMENT POLYLINE POLYGON ELLIPSE

CIRCLE

RECTANGLETRIANGLE

SQUARE

extent*barycenter*…

display*rotate…

perimeter*

perimeter+perimeter+

perimeter++diagonal

......

perimeter++perimeter++

+ +

side1side2

* deferred

+ effective

++ redefined


6


Redefinition

class POLYGON

create

make

feature

vertices: ARRAY [POINT]

vertices_count: INTEGER

perimeter: REAL is-- Perimeter length

dofrom ... until ... loop

Result := Result + (vertices @ i) . distance (vertices @ (i + 1))...

endend

invariant

vertices_count >= 3vertices_count = vertices.count

end

vertices @ i

vertices @ (i + 1)


7


Redefinition (cont’d)

class RECTANGLE

inherit

POLYGONredefine

perimeter end

create

make

featurediagonal, side1, side2: REAL

perimeter: REAL is-- Perimeter length

doResult := 2 * (side1 + side2)

end

invariantvertices_count = 4

end

side1

side2


8


Assume: p: POLYGON; r: RECTANGLE; t: TRIANGLE; x: REAL

Permitted:

x := p.perimeterx := r.perimeterx := r.diagonalp := r

NOT permitted: x := p.diagonal (even just after p := r !) r := p

Inheritance, typing and polymorphism

(POLYGON)

(RECTANGLE)

p

r


9


Dynamic binding

What is the effect of the following (assuming some_test true)?

if some_test thenp := r

elsep := t

endx := p.perimeter

Redefinition: A class may change an inherited feature, as with POLYGON redefining perimeter.

Polymorphism: p may have different forms at run-time.

Dynamic binding: Effect of p.perimeter depends on run-time form of p.


10


The meaning of inheritance

The type perspective: Automatic adaptation of operations to the

dynamic form of their targets (extendibility):Representation independence.

Factoring out reusable operations: Commonality.

The module perspective (reusability): Open-closed modules Modularity The Single Choice Principle


11


The traditional architecture

display (f: FIGURE) isdo

if ‘‘f is a CIRCLE’’ then ...

elseif ‘‘f is a POLYGON’’ then...

endend

and similarly for all other routines!


12


Applying the Single Choice Principle

f: FIGUREc: CIRCLEp: POLYGON...create c.make (...)create p.make (...)... if ... then

f := c else

f := p end...f.move (...)f.rotate (...)f.display (...)...


13


The Open-Closed Principle

A C E

D

B

F A’

G

H I


14


Issues

Representation independance:

Can a client request an operation such as table search (has) without knowing what implementation is used internally?

has (t1, y)

Now:

t1.has (y)


15


The dangers of static binding

For every creation procedure cp:

{precp} docp {postcp and INV}

For every exported routine r:

{INV and prer} dor {INV and postr}

The worst possible erroneous run-time situation in object-oriented software development: Producing an object that does not satisfy

the invariant of its class.

a.f (…)

a.g (…)

a.f (…)

create a.make (…)S1

S2

S3

S4


16


The dangers of static binding (cont’d)

{INVA} dorA {INVA}

{INVB} dorB {INVB}

Consider a call of the form a1.r where a1 is polymorphic: No guarantee on the effect of dorA on an instance

of B!

A

B

rA

rB++


17


A concrete example

w: WINDOWb: BUTTON

create b

w := bw.display

WINDOW

BUTTON

display

display++


18


Using original version of redefined feature

class BUTTON

inherit

WINDOWredefine

display end

feature

display isdo

Precursordisplay_borderdisplay_label

end

display_label is do

... end

display_border is do

... end

end


19


Use of Precursor

Not necessarily the first feature statement. May have arguments.

class B

inherit

Aredefine

my_feature end

feature

my_feature (args: SOME_TYPE) isdo

-- Something herePrecursor (args)-- Something else here

end

end

A

B

my_feature

my_feature++


20


Genericity + Inheritance 1: Polymorphic data structures

class STACK [G]

feature...item: G is ...put (x: G) is ...

end

fs: STACK [FIGURE]r: RECTANGLEs: SQUAREt: TRIANGLEp: POLYGON...fs.put (p); fs.put (t); fs.put (s); fs.put (r)fs.item.display

(SQUARE)

(RECTANGLE)

(TRIANGLE)

(POLYGON)

fs


21


Example hierarchy

FIGURE*

OPEN_ FIGURE

*CLOSED_ FIGURE

*

SEGMENT POLYLINE POLYGON ELLIPSE

CIRCLE

RECTANGLETRIANGLE

SQUARE

extent*barycenter*…

display*rotate…

perimeter*

perimeter+perimeter+

perimeter++diagonal

......

perimeter++perimeter++

+ +

side1side2

* deferred

+ effective

++ redefined


22


Genericity vs. Inheritance

LIST_OF_BOOKS

SET_OF_BOOKS

LIKED_LIST_OF_BOOKS

LIST_OF_PEOPLE

LIST_OF_JOURNALS

Abstraction

Specialization

Type parameterization Type parameterization


23


Forcing a type: the problem

fs.store ("FILE_NAME")...-- Two years later:

fs := retrieved ("FILE_NAME")x := fs.item -- [1]print (x.diagonal) -- [2]

But: If x is declared of type RECTANGLE, [1] is invalid. If x is declared of type FIGURE, [2] is invalid.


24


The solution: Assignment attempt

fs.store ("FILE_NAME")...-- Two years later:

fs ?= retrieved ("FILE_NAME")x := fs.item -- [1]print (x.diagonal) -- [2]

But: If x is declared of type RECTANGLE, [1] is invalid. If x is declared of type FIGURE, [2] is invalid.


25


Assignment attempt

f: FIGUREr: RECTANGLE...fs.retrieve ("FILE_NAME")f := fs.itemr ?= fif r /= Void then

print (r.diagonal)else

print ("Too bad.")end


26


Assignment attempt (cont’d)

x ?= y

with

x: A

If y is attached to an object whose type conforms to A, perform normal reference assignment.

Otherwise, make x void.


27


Genericity + Inheritance 2: Constrained genericity

class VECTOR [G]

feature

infix "+" (other: VECTOR [G]): VECTOR [G] is-- Sum of current vector and other

requirelower = other.lowerupper = other.upper

locala, b, c: G

do... See next ...

end

... Other features ...

end


28


Constrained genericity (cont’d)

The body of infix "+":

create Result.make (lower, upper)from

i := lower until

i > upper loop

a := item (i)b := other.item (i)c := a + b -- Requires a “+” operation on

G!Result.put (c, i)i := i + 1

end


29


Constrained genericity (cont’d)

The body of infix "+":

create Result.make (lower, upper)from

i := lower until

i > upper loop

a := item (i)b := other.item (i)c := a + b -- Requires a “+” operation on

G!Result.put (c, i)i := i + 1

end


30


The solution

Declare class VECTOR as

class VECTOR [G –> NUMERIC]

feature

... The rest as before ...

end

Class NUMERIC (from the Kernel Library) provides features infix "+", infix "*" and so on.

Better yet: make VECTOR itself a descendant of NUMERIC, effecting the corresponding features:


31


Improving the solution

Make VECTOR itself a descendant of NUMERIC, effecting the corresponding features:

class VECTOR [G –> NUMERIC]

inherit

NUMERIC

feature

... The rest as before, including infix "+"...

end

Then it is possible to define e.g.

v: VECTOR [VECTOR [VECTOR [INTEGER]]]


32


Inheritance and assertions

Correct call:

if a1. thena1.r (...)

else...

end

r isrequire

ensure

r isrequire

ensure

C A

B

a1: A

a1.r (…)…


33


Redefined version may not have require or ensure.

May have nothing (assertions kept by default), or

require else new_preensure then new_post

Resulting assertions are: original_precondition or new_pre original_postcondition and new_post

Assertion redeclaration rule


34


Invariant accumulation

Every class inherits all the invariant clauses of its parents.

These clauses are conceptually “and”-ed.


35


End of lecture 8

Documents

Chair of Software Engineering ATOT - Lecture 8, 28 April 2003 1 Advanced Topics in Object Technology Bertrand Meyer