Inheritance and Design by Contract & Genericity
-
Upload
indira-cunningham -
Category
Documents
-
view
27 -
download
2
description
Transcript of Inheritance and Design by Contract & Genericity
1
Inheritanceand
Design by Contract & Genericity
2
Parents Invariant Rule
• The invariants of all the parents of a class apply to the class itself
» The parent’s invariants are AND’ed together, along with the invariants of this class
» If no invariants are given then TRUE is assumed
• Flat and flat short forms provide a convenient way to see the whole story
» Flat is used by the supplier
» Flat short is used by the client
> Does not have class history – redefine, rename, etc.
3
Meaning of Design by Contract
C Ar is require ...
ensure end
-- In Ca1 : A
if a1. then a1.r
check a1. ... assume a1. is trueend
Verify preconditionsif not clear they are satisfied
Verify postconditions.Not needed with exceptionhandling
4
Enter Dynamic Binding
C Ar is require ...
ensure end
Br is require ...
ensure end
++
-- In Ca1 : Aa1 := instance of type Bif a1. ?pre? then a1.r check a1. ?post? ... assume a1. ?post? is trueend
What are ?pre?and ?post?
What restrictions are
on and ?
5
How to cheat
• Two ways
» C expects is sufficient but B has stronger preconditions
> don't accept all inputs
> demand more from client
> client is wrong
» C expects is delivered but B has weaker postcondition
> deliver outside the range
> effectively deliver less
-- In Ca1 : Aa1 := instance of type Bif a1. ?pre? then a1.r check a1. ?post? ... assume a1. ?post?end
6
Be Honest
• Replace precondition with a weaker precondition
» Expect less from the client than they are prepared to do
> require clause becomes weaker
• Replace postcondition with a stronger postcondition
» Deliver more to the client than they expect to get
> ensure clause becomes stronger
• Willing to do the job as good as or better
7
Design by Contract with Dynamic Binding
• Contracts cannot be broken by redefinition
• Assertions require and ensure are inherited
» Every behaviour of the redefined method satisfies the original contract
» But can do more
> Accept more input cases
> Deliver more specific outputs
8
Subcontracting
• Redefinition is like subcontracting
• To validate a subcontract requires a theorem prover for the general case
• This is inefficient so we provide an approximation
or > Weaker precondition is to accept or
and> Stronger postcondition is to accept and
9
Subcontracting – 2
• Language support
» When redefining do not use require and ensure
» Use require else
is or'ed with – the inherited precondition
» Use ensure then
is and'ed with – the inherited postcondition
10
Subcontracting example
invert (epsilon : REAL ) is -- Invert matrix with precision epsilon require else epsilon >= 10^(– 20) ... ensure then abs ((Current * inverse ) – Identity ) <= ( epsilon / 2 )end
invert (epsilon : REAL ) is -- Invert matrix with precision epsilon require epsilon >= 10^(– 6) ... ensure abs ((Current * inverse ) – Identity ) <= epsilonend
Original definition
Redefinition
11
Apparent Precondition Strengthening
• Consider the case of general containers that have no bounds on capacity
List implementation
• Inherit from List but have a bounded capacity container
Array implementation
• It looks like original has no restrictions when using add but refinement has restrictions
> cannot add when full
12
Apparent Precondition Strengthening – 2
• Actually have the following in the unbounded container
require not full
> With full defined as returning false
• In child define
full : BOOLEAN is Result := (count = Capacity ) end
• In client have
» if not container.full then container.add(...) end
• No changes and no surprises in the client
• Use abstract preconditions
13
Assertion Redeclaration Rule
• In the redeclared version of a routine it is not permitted to use a require or an ensure clause. Instead you may:
» Use a clause introduced by require else to be or'ed with the original precondition
» Use a clause introduced by ensure then to be and'ed with the original postcondition
• In the absence of such a clause the original is retained
• The lazy evaluation (non-strict) form of or else and and then are used
14
Redefining a function into an attribute
• Small problem here
» Precondition becomes the weaker True as the value can be accessed at any time
» But attributes do not have a postcondition
> The postcondition is added to the class invariant
> Thereby ensuring the contract still holds
foo : INTEGER is require xyz > 0 ... ensure Result = k + 1end
foo : INTEGER ... invariant foo = k + 1end
15
On Style
» Functions without arguments could be attributes
» Could have postcondition or use class invariants
> class invariants are the preferred style
16
Constrained Genericity
• Used when the generic type parameters must satisfy some conditions
• The following makes sense only if G has thefeature ≥
class RHINO [ G –> COMPARABLE] feature ... minimum ( x , y : G ) : G is do
if x ≥ y then Result := y else Result := x end ...end
17
Constrained Genericity – 2
• In general use the following syntax for constrained genericity
» class NAME [ TYPE –> CONSTRAINING_TYPE , ... ]
> DICTIONARY [ G , H –> HASHABLE ]
• The –> indicates inheritance
» H must be a type that inherits from HASHABLE
• Inheritance guarantees the type passed has all the features one needs in the context of its use
• Unconstrained genericity is really written as follows> STACK [ G –> ANY ]
18
Type Redeclaration Rule
• A redeclaration of a feature may replace the type of the feature (in an attribute or function) or the type of a formal argument (if a routine) by any type that conforms to the original
» See Redefining a Signature slides in the set on Inheritance and Adaptation
• While the rule guarantees proper typing inconsistencies can arise if types are not changed consistently
» Leads to use of Anchored Declarations
> The ability to define types relatively and not absolutely
19
Anchored Declaration
• Provide a shortcut for certain kinds of signature redefinitions
• Declarations can be made relative to an anchor type rather than providing an absolute declaration
class NODE [ G ] creation make feature { NONE } item : G -- what's held in the node next : like Current feature { ANY } make (g : G ) ... change_item ( g : G ) change_next ( other : like next )
end -- NODE
Current is the anchor.next points to a nodeof the same type asCurrent
other is same type asNext – recursive to Current
20
Anchored Declaration – Rules
• The base class of like anchor is
» the base class of the type of anchor in the current class
» If anchor is Current, then the base class is the enclosing class
• Can have recursive definition
» like anchor can be based on an anchored type
» Do not have cycles in the anchor chain – no knots
• While like anchor conforms to its base class T, T does not conform to like anchor
» Problems occur if the anchor is redeclared in a subclass (see p603)
21
Information Hiding & Inheritance
• Inheritance and Information Hiding are orthogonal mechanisms
» If B inherits from A
> B is free to export or hide any feature it inherits in all possible combinations
» Need an export clause to change the export status from that of the parent
class B inherit A export { NONE } f end -- f is secret export { ANY } g end -- g is public export { X, Y } h end -- h is selectively public... -- to X, Y and their descendantsend
22
Interface & Implementation Use
Client Inheritance
Use through interface
Information hiding
Protection against changesin original implementation
Use of implementation
No information hiding
No protection against changesin original implementation
23
Multiple & RepeatedInheritance
24
Multiple Inheritance – Example
• Combining two abstractions into one
» COMPARABLE and NUMERIC are both useful abstractions
> Some abstractions make use of both while others do not
COMPARABLE NUMERIC
STRING INTEGER COMPLEX
25
Repeated Inheritance – Example
UNIVERSITY_PERSON
TEACHER STUDENT
TEACHING_ASSISTANT
• Ancestor used in multiple paths to descendant
26
Inheritance Types
• Structural – an abstraction that combines two types of structures
» ARRAY_STACK is both a STACK and an ARRAY
• Facility – abstractions that combine two sets of features
» HISTORY and STORABLE
• Buttonhole – Combining external models
» COMPANY_PLANE, SLEEPING_CAR
» Buttons and holes as in the EStudio interface
27
Feature Renaming
• Multiple & repeated inheritance lead to name clashes
» What if two parents use the same name for a feature?
> A common occurrence since good names are reused
» How can the child refer to the appropriate feature?
• Answer
» Rename one of the features – give it an alias
> Do not rely on overloading, not enough variation– distinguish features by argument type and count
28
Example Renaming
• Suppose LONDON and LOS_ANGELES both have the feature foo
• Then we can define TORONTO as follows
class TORONTO inherit LONDON rename foo as fog end redefine ... end LOS_ANGELES rename foo as smog end redefine ... endfeature ...end -- TORONTO
29
Renaming Effects
ldon : LONDON ; la : LOS_ANGELES ; tor : TORONTO
Valid – even after polymorphic assignment
ldon.foo ; tor.fogla.foo ; tor.smog
Invalid
ldon.fog ; ldon.smogla.fog ; la.smogtor.foo
30
Redefinition & Renaming
• Redefinition
» Keeps the name, changes the semantics
• Renaming
» Keeps the semantics changes the name
• Can both rename and redefine
» Rename first
» Use new name when redefining
• Renaming can be useful to change the name to a more common one for the abstraction
» TO push & pop (STACK) FROM add and remove (CONTAINER)
31
Repeated Inheritance
• Indirect
» class B inherit Aclass C inherit Aclass D inherit B C
• Direct
» class B inherit A A
A
B
D
C
A
B
32
Problems
DRIVERage pass_birthdayaddress pay_feeviolation_count
FRENCH_DRIVER
US_DRIVER
FRENCH_US_DRIVER
What about age?It is the same forboth drivers!
DO NOT rename!
Only rename ifinheriting differentbut identicallynamed features
Have a singleshared feature
Sharing is not always appropriate – violation_count, address, pay_fee –are all different – need to replicate for each driver
33
Repeated Inheritance Rule
• In a repeated inheritance
» Versions of a repeatedly inherited feature inherited under the same name represent a single feature
» Versions inherited under different names represent separate features, each replicated from the original in the common ancestor
> Use rename to get replication– rename pay_fee as pay_french_fee
• The rule applies to attributes as well as routines
34
Single Name Rule
• Definition
» The final name of a feature in a class is
> For an immediate feature, the name under which it is declared
> For an inherited feature that is not renamed, its final name is (recursively) in the parent from which it is inherited
> For a renamed feature, the name resulting from the renaming
• Single Name Rule
» Two different effective features of a class may not have the same final name
35
Must Rename
• Consider the following attributes, even if the types agree must rename problem in D
» Rename either version from B or C or both
D
Bproblem C problem
36
Conflicting Redefinition
• In D have two different definitions of f
» From B and from A through C
• Consider under
» sharing
» replication
A
B
D
C
f
f++
37
Conflict Resolution – Sharing
• Inherit under same name
» one version is deferred other is effective
> No problem – single name rule
» both versions effective but redefined in D
> No problem – produce one redefined version
A
B
D
C
f
f++
» both effective, no redefinition
> Problem – name clash, must rename, get replication
38
Conflict Resolution – Sharing – 2
• Other solutions
» Make one of the versions deferred – Other takes over
> undefine
» Different names – join the solutions
> Requires compatible signatures and semantics
class D inherit B C rename g as f undefine f....
class D inherit B C undefine f end....
D
B Cf g
39
Conflict Resolution – Replication
• Suppose a1 := instance of D
» Then a1.f is ambiguous
> could be either f or bf
• Programmer must select the version
A
B
D
C
f
bf++
f
class D inherit B C select f end....
class D inherit B select bf end C....
40
Select Rule
• A class that inherits two or more different effective versions of a feature from a repeated ancestor and does not redefine them both, must include exactly one of them in a select clause
» Use select all end if that is desired
41
Genericity with Repeated Inheritance
• The type of any feature that is shared under the repeated inheritance rule, and the type of any of its arguments if it is a routine, may not be a generic parameter of the class from which the feature is repeatedly inherited
» Ambiguity as to the type for f in B.
» Use renaming to get replication, if genericity is needed
class A[G] feature f : Gend
class B inherit A [INTEGER] A [REAL]end
42
Name Clashes – Definition & Rule
• In a class obtained through multiple inheritance, a name clash occurs when two features inherited from different parents have the same final name
• A name clash makes the class invalid except in any of the following cases
» The two features are inherited from a common ancestor and none has been redeclared from the version in that ancestor
» Both features have compatible signatures and at least one of them is inherited in deferred form
» Both features have compatible signatures and they are both redefined in the class
> As one redefinition for the feature
43
Summary of Adaptation Clauses
• Eiffel adaptation clauses are in the following order.
class B
inherit A
rename f1 as new_f1, f2 as new_f2, f3 as new_f3
export {A, B} new_f1, f4
redefine new_f2, f5
undefine new_f3, f6
select new_f2, f7
end