Chair of Software Engineering OOSC - Summer Semester 2005 1 Bertrand Meyer Object-Oriented Software...
-
date post
19-Dec-2015 -
Category
Documents
-
view
217 -
download
1
Transcript of Chair of Software Engineering OOSC - Summer Semester 2005 1 Bertrand Meyer Object-Oriented Software...
OOSC - Summer Semester 2005
1
Chair of Software Engineering
Bertrand Meyer
Object-Oriented Software Construction
Lecture 8: More on inheritance
OOSC - Summer Semester 2005
2
Chair of Software Engineering
Agenda for today
Constrained genericity Creating with a specified type Once routines Multiple inheritance
OOSC - Summer Semester 2005
3
Chair of Software Engineering
Agenda for today
Constrained genericity Creating with a specified type Once routines Multiple inheritance
OOSC - Summer Semester 2005
4
Chair of Software Engineering
Adding two vectors
+ =u v w
i a b c
OOSC - Summer Semester 2005
5
Chair of Software Engineering
Constrained genericity
classVECTOR [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
OOSC - Summer Semester 2005
6
Chair of Software Engineering
Constrained genericity
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
OOSC - Summer Semester 2005
7
Chair of Software Engineering
Adding two vectors
+ =u v w
i a b c
OOSC - Summer Semester 2005
8
Chair of Software Engineering
Constrained genericity: The solution
Declare class VECTOR as
classVECTOR [G –> NUMERIC]
feature... The rest as before ...
end
Class NUMERIC (from the Kernel Library) provides features infix "+", infix "*" and so on.
OOSC - Summer Semester 2005
9
Chair of Software Engineering
Improving the solution
Make VECTOR itself a descendant of NUMERIC, effecting the corresponding features:
classVECTOR [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]]]
OOSC - Summer Semester 2005
10
Chair of Software Engineering
Agenda for today
Constrained genericity Creating with a specified type Once routines Multiple inheritance
OOSC - Summer Semester 2005
11
Chair of Software Engineering
Creating with a specified type
To avoid this:
a1: Ab1: B...create b1.make (...)a1 := b1
Simply use
a1: A...create {B} a1.make (...)
B
A
(See factory pattern)
OOSC - Summer Semester 2005
12
Chair of Software Engineering
Agenda for today
Constrained genericity Creating with a specified type Once routines Multiple inheritance
OOSC - Summer Semester 2005
13
Chair of Software Engineering
Once routines
If instead of
r isdo
... Instructions ...end
you write
r isonce
... Instructions ...end
then Instructions will be executed only for the first call by any client during execution. Subsequent calls return immediately.
In the case of a function, subsequent calls return the result computed by the first call.
OOSC - Summer Semester 2005
14
Chair of Software Engineering
Scheme for shared objectsclass
SHARED_OBJECTS feature
error_window: WINDOW isonce
create Result.make (...) end
exit_button: BUTTON isonce
create Result.make (...) end
end
classMY_APPLICATION_CLASS
inheritSHARED_OBJECTS
feature
r is do
error_window.put (my_error_message)end
end
OOSC - Summer Semester 2005
15
Chair of Software Engineering
Agenda for today
Constrained genericity Creating with a specified type Once routines Multiple inheritance
OOSC - Summer Semester 2005
16
Chair of Software Engineering
Multiple inheritance
Allow a class to have two or more parents.
Examples that come to mind: ASSISTANT inherits from TEACHER and STUDENT.
TEACHER STUDENT
ASSISTANT
OOSC - Summer Semester 2005
17
Chair of Software Engineering
Example: Teaching assistant
This is in fact a case of repeated inheritance:
TEACHER STUDENT
ASSISTANT
UNIVERSITY_MEMBER id
????
????
OOSC - Summer Semester 2005
18
Chair of Software Engineering
Other examples of multiple inheritance
Combining separate abstractions:
Restaurant, train car Calculator, watch Plane, asset
OOSC - Summer Semester 2005
19
Chair of Software Engineering
Multiple inheritance: Combining abstractions
COMPARABLE NUMERIC
STRING COMPLEX
INTEGER
REAL
DOUBLE
OOSC - Summer Semester 2005
20
Chair of Software Engineering
Multiple inheritance: Composite figures
A composite figure
Simple figures
OOSC - Summer Semester 2005
21
Chair of Software Engineering
Defining the notion of composite figure
FIGURELIST
[FIGURE]
COMPOSITE_FIGURE
displayhiderotatemove
countputremove
OOSC - Summer Semester 2005
22
Chair of Software Engineering
Composite figures through multiple inheritance
FIGURE LIST [FIGURE]
COMPOSITE_FIGUREOPEN_FIGURE
CLOSED_FIGURE
SEGMENT POLYLINE POLYGON ELLIPSE
RECTANGLE
SQUARE
CIRCLETRIANGLE
perimeter+
perimeter*
perimeter++
perimeter++
perimeter++
perimeter+
diagonal
OOSC - Summer Semester 2005
23
Chair of Software Engineering
A composite figure as a list
start
item
forth after
OOSC - Summer Semester 2005
24
Chair of Software Engineering
Composite figuresclass
COMPOSITE_FIGURE
inherit
FIGUREredefine display, move, rotate, ... end
LIST [FIGURE]
feature
display is-- Display each constituent figure in turn.
dofrom start until after loop
item.displayforth
endend
... Similarly for move, rotate etc. ...
end
OOSC - Summer Semester 2005
25
Chair of Software Engineering
Complex figures
A simpler form of procedures display, move etc. can be obtained through the use of iterators.
We’ll learn to use agents for that purpose.
OOSC - Summer Semester 2005
26
Chair of Software Engineering
Multiple inheritance
INTEGER
NUMERICCOMPARABLE
REAL
DOUBLESTRING MATRIX
* *
OOSC - Summer Semester 2005
27
Chair of Software Engineering
Multiple inheritance from interfaces: limitations
It is often useful to have a mix of abstract and concrete (“effective”) features
Eiffel “deferred” classes permit this. Not possible in Java and the .NET object
model Java experience shows that programmers
resort to various ugly tricks to simulate this… (See John Viega, TOOLS USA 2000)
OOSC - Summer Semester 2005
28
Chair of Software Engineering
infix "<=" (other: COMPARABLE [G]): BOOLEAN is
doResult := Current < other or
equal (Current, other)end
infix ">=" (other: COMPARABLE [G]) is …infix ">" (other: COMPARABLE [G]) is ……
deferred class COMPARABLE [G] featureinfix "<" (other: COMPARABLE [G]): BOOLEAN
isdeferredend
end -- class COMPARABLE
OOSC - Summer Semester 2005
29
Chair of Software Engineering
Multiple inheritance: Name clashes
A
C
foofoo
B
OOSC - Summer Semester 2005
30
Chair of Software Engineering
Resolving name clashes
A
C
foofoo
B
rename foo as fog rename foo as zoo
OOSC - Summer Semester 2005
31
Chair of Software Engineering
Resolving name clashes
classC
inheritA
renamefoo as fog
end
Brename
foo as zooend
feature...
OOSC - Summer Semester 2005
32
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 2005
33
Chair of Software Engineering
When is a name clash acceptable?
(Between n features of a class, all with the same name, immediate or inherited.)
They must all have compatible signatures.
If more than one is effective, they must all come from a common ancestor feature under repeated inheritance.
OOSC - Summer Semester 2005
34
Chair of Software Engineering
Another application of renaming
Provide locally better adapted terminology.
Example: child (TREE); subwindow (WINDOW).
OOSC - Summer Semester 2005
35
Chair of Software Engineering
Feature merging
A B C
D
f* f* f+
OOSC - Summer Semester 2005
36
Chair of Software Engineering
Feature merging (cont’d)
class D inherit
A
B
C
feature
...
end
OOSC - Summer Semester 2005
37
Chair of Software Engineering
Feature merging: with different names
A B C
D
g* f* h+
g f h f
OOSC - Summer Semester 2005
38
Chair of Software Engineering
Feature merging: with different names
class D inherit
Arename
g as f end
B
Crename
h as f end
feature...
end
OOSC - Summer Semester 2005
39
Chair of Software Engineering
Feature merging: effective features
a1: A b1: B c1: C d1: Da1.g b1.f c1.h d1.f
A B C
D
g+f+ h+
g f h ff- f-
OOSC - Summer Semester 2005
40
Chair of Software Engineering
Feature merging: effective features
class D inherit
Arename
g as f undefine
fend
B
Crename
h as f undefine
fend
feature...
end
OOSC - Summer Semester 2005
41
Chair of Software Engineering
End of lecture 8