Post on 19-Dec-2015
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