Object-Oriented Software Construction Bertrand Meyer Lesson 21
Chair of Software Engineering OOSC - Lecture 21 1 Object-Oriented Software Construction Bertrand...
-
date post
21-Dec-2015 -
Category
Documents
-
view
214 -
download
0
Transcript of Chair of Software Engineering OOSC - Lecture 21 1 Object-Oriented Software Construction Bertrand...
OOSC - Lecture 21
1
Chair of Software Engineering
Object-Oriented Software Construction
Bertrand Meyer
OOSC - Lecture 21
2
Chair of Software Engineering
Lecture 21:
Typing issues, covariance
OOSC - Lecture 21
3
Chair of Software Engineering
The America Conjecture
(Pierre America at TOOLS Europe 1990)
One can have at most two of the three properties of: Static typing. Substitutivity. Covariance.
Can we disprove the America conjecture?
OOSC - Lecture 21
4
Chair of Software Engineering
Typing: A simple problem!
The basic operation of object-oriented computation:
x.f (arg)
OOSC - Lecture 21
5
Chair of Software Engineering
The typing problem
When, and how, do we know that:
There is a feature applicable to OBJ and corresponding to f?
arg is an acceptable argument for that feature?
OOSC - Lecture 21
6
Chair of Software Engineering
Terminology
x: Entity.OBJ: The object attached to x at some time during
execution.f: Routine (One of the two forms of feature;
the other is attributes.)
x OBJ
OOSC - Lecture 21
7
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 - Lecture 21
8
Chair of Software Engineering
Inheritance and typing
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 - Lecture 21
9
Chair of Software Engineering
Cost of correcting errors (Boehm)
Requirements Design Code Development Acceptance Operationtest test
SMALL PROJECTS
LARGE PROJECTS
OOSC - Lecture 21
10
Chair of Software Engineering
Typing rules (all locally checkable)
Declaration rule. Call rule. Attachment rule.
(For the precise formulations see Eiffel: The Language.)
OOSC - Lecture 21
11
Chair of Software Engineering
Declaration rule
Every entity must be declared as being of a certain type.
For example:
x: AIRCRAFT
n: INTEGER
ba1: BANK_ACCOUNT
OOSC - Lecture 21
12
Chair of Software Engineering
Call rule
If a class C contains the call
x.f
there must be a feature of name f in the base class of the type of x, and that feature must be available (exported) to C.
OOSC - Lecture 21
13
Chair of Software Engineering
Attachment rule
In an assignment x := y, or the corresponding argument passing, the base class of the type of y must be a descendant of the base class of the type of x.
OOSC - Lecture 21
14
Chair of Software Engineering
For typing to be acceptable
No exception to type ee-rules (“casts”).
Multiple inheritance
Unconstrained genericity:
class LIST [G] ...
Constrained genericity:
class VECTOR [G –> NUMERIC] ...
OOSC - Lecture 21
15
Chair of Software Engineering
For typing to be acceptable (cont’d)
Assignment attempt:
x ?= y
Contracts, to clarify the semantics and include constraints other than typing (e.g. numerical ranges).
Covariance for routine arguments.
Anchored declarations (like x) to avoid endless redeclarations.
OOSC - Lecture 21
16
Chair of Software Engineering
Multiple inheritance
DOCUMENT MESSAGE
MAILABLE_ DOCUMENT
OOSC - Lecture 21
17
Chair of Software Engineering
A class hierarchy
DRIVER
BIKERTRUCKER
HEAVY_TRUCKER
partner: DRIVER
share (other: DRIVER)
partner++
share++
partner++
share++
partner++
share++
OOSC - Lecture 21
18
Chair of Software Engineering
Choosing a partner
class DRIVER
feature
partner: DRIVER-- This driver’s alternate
share (other: DRIVER) is-- Choose other as alternate.
requireother /= Void
dopartner := other
end
...
end
OOSC - Lecture 21
19
Chair of Software Engineering
d1, d2: DRIVER...d1.share (d2)
A typical call
OOSC - Lecture 21
20
Chair of Software Engineering
Specializing
class TRUCKER
inherit
DRIVERredefine
partnerend
feature
partner: TRUCKER-- This driver’s alternate.
...
end
OOSC - Lecture 21
21
Chair of Software Engineering
The need for covariance
class TRUCKER
inherit
DRIVERredefine
partner,share
end
feature
partner: TRUCKER-- This driver’s alternate.
share (other: TRUCKER) is-- Choose other as alternate.
requireother /= Void
dopartner := other
end
end
OOSC - Lecture 21
22
Chair of Software Engineering
Direct covariance
DRIVER
BIKERTRUCKER
HEAVY_TRUCKER
partner: DRIVER
share (other: DRIVER)
partner++
share++
partner++
share++
partner++
share++
OOSC - Lecture 21
23
Chair of Software Engineering
Anchored declarations:
class TRUCKER
inherit
DRIVERredefine
partner,share
end
feature
partner: TRUCKER-- This driver’s alternate.
share (other: like partner) is-- Choose other as alternate.
requireother /= Void
dopartner := other
end
end
Avoiding redefinition avalanche
OOSC - Lecture 21
24
Chair of Software Engineering
End of lecture 22