Chair of Software Engineering OOSC Summer Semester 2004 1 Object-Oriented Software Construction Bertrand Meyer.

Post on 19-Dec-2015

216 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

Transcript

OOSC Summer Semester 2004

1

Chair of Software Engineering

Object-Oriented Software Construction

Bertrand Meyer

OOSC Summer Semester 2004

2

Chair of Software Engineering

Lecture 8: Inheritance

OOSC Summer Semester 2004

3

Chair of Software Engineering

Typing vs. binding

What do we know about the feature to be called?

Static typing:

At least one

Dynamic binding:

The right one

Example:

my_aircraft.lower_landing_gear

OOSC Summer Semester 2004

4

Chair of Software Engineering

Example hierarchy

AIRCRAFT*

PLANE*

COPTER*

BOEING AIRBUS

A_320B_747B_737

B_747_400

* deferred+ effected++ redefined

lower_landing_gear*

lower_landing_gear++

lower_landing_gear+

OOSC Summer Semester 2004

5

Chair of Software Engineering

(After Barry W. Boehm)

Requirements Design Code Development Acceptance Operationtest test

SMALL PROJECTS

LARGE PROJECTS

OOSC Summer Semester 2004

6

Chair of Software Engineering

Multiple inheritance

A class may have two or more parents.

What not to use as an elementary example: TEACHING_ASSISTANT inherits from TEACHER and STUDENT.

TEACHER STUDENT

TEACHING_ASSISTANT

OOSC Summer Semester 2004

7

Chair of Software Engineering

The teaching assistant example

This is in fact a case of repeated inheritance:

TEACHER STUDENT

TEACHING_ASSISTANT

UNIVERSITY_MEMBER

id

????

????

OOSC Summer Semester 2004

8

Chair of Software Engineering

Common examples of multiple inheritance

Combining separate abstractions: Restaurant, train car Calculator, watch Plane, asset

OOSC Summer Semester 2004

9

Chair of Software Engineering

Multiple inheritance: Combining abstractions

COMPARABLE NUMERIC

STRING COMPLEX

INTEGER

REAL

DOUBLE

* *

OOSC Summer Semester 2004

10

Chair of Software Engineering

Multiple inheritance: Nested windows

‘‘Graphical’’ features: height, width, change_height, change_width, xpos, ypos, move...

‘‘Hierarchical’’ features: superwindow, subwindows, change_subwindow, add_subwindow...

class WINDOW inherit

RECTANGLE

TREE [WINDOW]

feature...

end

OOSC Summer Semester 2004

11

Chair of Software Engineering

Multiple inheritance: Composite figures

A composite figure

Simple figures

OOSC Summer Semester 2004

12

Chair of Software Engineering

Defining the notion of composite figure

FIGURELIST

[FIGURE]

COMPOSITE_FIGURE

*display*

hiderotatemove…

countputremove…

display+

OOSC Summer Semester 2004

13

Chair of Software Engineering

Defining the notion of composite figure through multiple inheritance

FIGURELIST

[FIGURE]

COMPOSITE_FIGURE

*

OPEN_ FIGURE

CLOSED_ FIGURE

SEGMENT POLYLINE

POLYGON ELLIPSE

RECTANGLE

SQUARE

CIRCLE TRIANGLE

perimeter+

perimeter*

perimeter++

perimeter++

perimeter++

perimeter+

diagonal …

OOSC Summer Semester 2004

14

Chair of Software Engineering

A composite figure as a list

start

item

forth after

OOSC Summer Semester 2004

15

Chair of Software Engineering

Composite figures

class COMPOSITE_FIGURE inherit

FIGUREredefine display, move, rotate, ... end

LIST [FIGURE]

feature

display is-- Display each constituent figure in turn.

dofrom

start

untilafter

loopitem.displayforth

endend

... Similarly for move, rotate etc. ...

end

OOSC Summer Semester 2004

16

Chair of Software Engineering

Complex figures

Note: a simpler form of procedures display, move etc. can be obtained through the use of iterators.

Exercise: Use agents for that purpose.

OOSC Summer Semester 2004

17

Chair of Software Engineering

Name clashes under multiple inheritance

A

C

foofoo

B

OOSC Summer Semester 2004

18

Chair of Software Engineering

Resolving name clashes

A

C

foofoo

B

rename foo as fog rename foo as zoo

OOSC Summer Semester 2004

19

Chair of Software Engineering

Resolving name clashes (cont’d)

class C inherit

Arename

foo as fogend

Brename

foo as zooend

feature...

OOSC Summer Semester 2004

20

Chair of Software Engineering

Results of renaming

a1: Ab1: Bc1: C...c1.fogc1.zooa1.foob1.foo

Invalid:a1.fog, a1.zoo, b1.zoo, b1.fog, c1.foo

OOSC Summer Semester 2004

21

Chair of Software Engineering

Another application of renaming

Provide locally better adapted terminology.

Example: child (TREE); subwindow (WINDOW).

OOSC Summer Semester 2004

22

Chair of Software Engineering

The marriage of convenience

class ARRAYED_STACK [G] inherit

STACK [G]

ARRAY [G]

feature...

end

class LINKED_STACK [G] inherit

STACK [G]

LINKED_LIST [G]

feature...

end

OOSC Summer Semester 2004

23

Chair of Software Engineering

The need for deferred classes

In the scheme seen earlier:

f: FIGURE; c: CIRCLE; p: POLYGON...create c.make (...); create p.make (...)... if ... then

f := c else

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

How do we ensure that a call such as f.move (...) is valid even though there is no way to implement a general-purpose feature move for class FIGURE?

OOSC Summer Semester 2004

24

Chair of Software Engineering

Deferred classes

deferred class FIGURE feature

move (v: VECTOR) isdeferredend

rotate (a: ANGLE; p: POINT) isdeferredend

... display, hide, ...

end

Not permitted:

create f ...

OOSC Summer Semester 2004

25

Chair of Software Engineering

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++

OOSC Summer Semester 2004

26

Chair of Software Engineering

Deferred classes and features

A feature is either deferred or effective.

To effect a inherited feature (deferred in the parent) is to make it effective. No need for redefine clause.

Like a feature, a class is either deferred or effective.

A class is deferred if it has at least one deferred feature (possibly coming from an ancestor) that it does not effect. It is effective otherwise.

A deferred class may not be instantiated.

BUT: A deferred class may have assertions (in particular, a deferred routine may have a precondition and a postcondition, and the class may have a class invariant).

OOSC Summer Semester 2004

27

Chair of Software Engineering

Deferred classes

Compare with Ada-Modula 2-Java interface/body separation:

May contain both deferred and non-deferred elements.

More than one implementation is possible.

Formal semantic specification (assertions).

OOSC Summer Semester 2004

28

Chair of Software Engineering

Table variants

TABLE*

SEQUENTIAL_TABLE

*

LINKED_TABLE

+ARRAY_TABLE

+FILE_ TABLE

+

OOSC Summer Semester 2004

29

Chair of Software Engineering

Don’t call us, we’ll call you

deferred class SEQUENTIAL_TABLE [G] inherit

TABLE [G]

feature

has (x: G): BOOLEAN is-- Does x appear in table?

dofrom

start until

after or else equal (item, x) loop

forthendResult := not after

end

OOSC Summer Semester 2004

30

Chair of Software Engineering

SEQUENTIAL_TABLE (cont’d)

forth is-- Move cursor to the next position.

requirenot after

deferredensure

position = old position + 1end

start is-- Move cursor to the first position.

deferredensure

empty or else position = 1end

OOSC Summer Semester 2004

31

Chair of Software Engineering

SEQUENTIAL_TABLE (end)

position: INTEGER is deferred end

... empty, found, after, ...

invariant

0 <= positionposition <= size + 1empty implies (after or before)

end

OOSC Summer Semester 2004

32

Chair of Software Engineering

Descendant implementations

TABLE*

SEQUENTIAL_TABLE

*

LINKED_TABLE

+ARRAY_TABLE

+FILE_ TABLE

+

has+forth*item*start*

forth+item+start+

after+forth+item+start+

after+forth+item+start+

after+

after*

has*

OOSC Summer Semester 2004

33

Chair of Software Engineering

Descendant implementations (cont’d)

SEQUENTIAL_TABLE

*

LINKED_TABLE

+ARRAY_TABLE

+FILE_ TABLE

+

has+

forth*item*start*

forth+item+start+

after+forth+item+start+

after+forth+item+start+

after+

after*

OOSC Summer Semester 2004

34

Chair of Software Engineering

Implementation variants

Array

Linked list

File

start forth after item (x)

c := first_cell

rewind

i := 1

c := c.right

i := i + 1

read end_of_file

c := Void

f

c.item

i > count t [i]

OOSC Summer Semester 2004

35

Chair of Software Engineering

End of lecture 8

top related