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

2. Chair of Software Engineering OOSC Summer Semester 2004 2 Lecture 7: Inheritance by Piotr Nienaltowski

3. Chair of Software Engineering OOSC Summer Semester 2004 3 What do you want to learn today?  What is inheritance?  Redefinition of features  Polymorphism and dynamic binding  Inheritance and Design by Contract  Inheritance vs. genericity  Assignment attempt

4. Chair of Software Engineering OOSC Summer Semester 2004 4 What is inheritance?  Principle: Describe a new class not from scratch but as extension or specialization of one existing class — or several in the case of MULTIPLE inheritance.  From the module viewpoint: if B inherits from A, all the services of A are potentially available in B (possibly with a different implementation).  From the type viewpoint: inheritance is the ‘‘is- plus-but-except’’ relation. If B inherits from A, whenever an instance of A is required, an instance of B will be acceptable.

5. Chair of Software Engineering OOSC Summer Semester 2004 5 Terminology  Parent, Heir  Ancestor, Descendant  The ancestors of B are B itself and the ancestors of its parents.  Proper ancestor, Proper descendant  Direct instance, Instance  The instances of A are the direct instances of its descendants.  (Other terminology: subclass, superclass, base class) A B feature

6. Chair of Software Engineering OOSC Summer Semester 2004 6 Example hierarchy FIGURE * OPEN_ FIGURE * CLOSED_ FIGURE * SEGMENTPOLYLINEPOLYGONELLIPSE CIRCLE RECTANGLETRIANGLE SQUARE extent* barycenter* … display* rotate … perimeter* perimeter+ perimeter++ diagonal... perimeter++ ++ side1 side2 * deferred + effective ++ redefined

7. Chair of Software Engineering OOSC Summer Semester 2004 7 Redefinition class POLYGON create make feature vertices: ARRAY [POINT] vertices_count: INTEGER perimeter: REAL is -- Perimeter length do from... until... loop Result := Result + (vertices @ i). distance (vertices @ (i + 1))...end invariant vertices_count >= 3 vertices_count = vertices.count end vertices @ i vertices @ (i + 1)

8. Chair of Software Engineering OOSC Summer Semester 2004 8 class RECTANGLE inherit POLYGON redefine perimeter end create make feature diagonal, side1, side2: REAL perimeter: REAL is -- Perimeter length do Result := 2 * (side1 + side2) end invariant vertices_count = 4 end Redefinition (cont’d) side1 side2

9. Chair of Software Engineering OOSC Summer Semester 2004 9  Assume: p: POLYGON; r: RECTANGLE; t: TRIANGLE; x: REAL   Permitted: x := p.perimeter x := r.perimeter x := r.diagonal p := r  NOT permitted: x := p.diagonal (even just after p := r !) r := p Inheritance, typing and polymorphism (POLYGON) (RECTANGLE) p r

10. Chair of Software Engineering OOSC Summer Semester 2004 10 Dynamic binding  What is the effect of the following (assuming some_test true)? if some_test then p := r else p := t end x := p.perimeter  Redefinition: A class may change an inherited feature, as with RECTANGLE redefining perimeter.  Polymorphism: p may have different forms at run-time.  Dynamic binding: Effect of p.perimeter depends on run-time form of p.

11. Chair of Software Engineering OOSC Summer Semester 2004 11 The meaning of inheritance  The type perspective:  Automatic adaptation of operations to the dynamic form of their targets (extendibility): Representation independence.  Factoring out reusable operations: Commonality.  The module perspective (reusability):  Open-closed modules  Modularity  The Single Choice Principle

12. Chair of Software Engineering OOSC Summer Semester 2004 12 The traditional architecture display (f: FIGURE) is do if ‘‘f is a CIRCLE’’ then... elseif ‘‘f is a POLYGON’’ then... end and similarly for all other routines!

13. Chair of Software Engineering OOSC Summer Semester 2004 13 Applying the Single Choice Principle 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 (...)...

14. Chair of Software Engineering OOSC Summer Semester 2004 14 The Open-Closed Principle ACE D B FA’ G H I

15. Chair of Software Engineering OOSC Summer Semester 2004 15 The dangers of static binding  For every creation procedure cp: {pre cp } do cp {post cp and INV}  For every exported routine r: {INV and pre r } do r {INV and post r }  The worst possible erroneous run-time situation in object-oriented software development:  Producing an object that does not satisfy the invariant of its class. a.f (…) a.g (…) a.f (…) create a.make (…) S1 S2 S3 S4

16. Chair of Software Engineering OOSC Summer Semester 2004 16 The dangers of static binding (cont’d)  {INV A } do r A {INV A }  {INV B } do r B {INV B }  Consider a call of the form a1.r where a1 is polymorphic:  No guarantee on the effect of do r A on an instance of B! A B rArA r B ++

17. Chair of Software Engineering OOSC Summer Semester 2004 17 A concrete example w: WINDOW b: BUTTON create b w := b w.display WINDOW BUTTON display display++

18. Chair of Software Engineering OOSC Summer Semester 2004 18 Using original version of redefined feature class BUTTON inherit WINDOW redefine display end feature display is do Precursor display_border display_label end display_label is do... end display_border is do... end

19. Chair of Software Engineering OOSC Summer Semester 2004 19 Use of Precursor  Not necessarily the first feature statement.  May have arguments. class B inherit A redefine my_feature end feature my_feature (args: SOME_TYPE) is do -- Something here Precursor (args) -- Something else here end A B my_feature my_feature++

20. Chair of Software Engineering OOSC Summer Semester 2004 20 Inheritance and assertions Correct call: if a1. then a1.r (...) else... end r is require  ensure  r is require  ensure  CA B a1: A a1.r (…) …

21. Chair of Software Engineering OOSC Summer Semester 2004 21  Redefined version may not have require or ensure.  May have nothing (assertions kept by default), or require else new_pre ensure then new_post  Resulting assertions are:  original_precondition or new_pre  original_postcondition and new_post Assertion redeclaration rule

22. Chair of Software Engineering OOSC Summer Semester 2004 22 Invariant accumulation  Every class inherits all the invariant clauses of its parents.  These clauses are conceptually “and”-ed.

23. Chair of Software Engineering OOSC Summer Semester 2004 23 Genericity vs. Inheritance LIST_OF_ BOOKS SET_OF_ BOOKS LINKED_LIST _OF_BOOKS LIST_OF_ PEOPLE LIST_OF_ JOURNALS Abstraction Specialization Type parameterization

24. Chair of Software Engineering OOSC Summer Semester 2004 24 Genericity + Inheritance 1: Polymorphic data structures class STACK [G] feature... item: G is... put (x: G) is... end fs: STACK [FIGURE] r: RECTANGLE s: SQUARE t: TRIANGLE p: POLYGON... fs.put (p); fs.put (t); fs.put (s); fs.put (r) fs.item.display (SQUARE) (RECTANGLE) (TRIANGLE) (POLYGON) fs

25. Chair of Software Engineering OOSC Summer Semester 2004 25 Example hierarchy FIGURE * OPEN_ FIGURE * CLOSED_ FIGURE * SEGMENTPOLYLINEPOLYGONELLIPSE CIRCLE RECTANGLETRIANGLE SQUARE extent* barycenter* … display* rotate … perimeter* perimeter+ perimeter++ diagonal... perimeter++ ++ side1 side2 * deferred + effective ++ redefined

26. Chair of Software Engineering OOSC Summer Semester 2004 26 Genericity + Inheritance 2: Constrained genericity class VECTOR [G -> NUMERIC] feature infix "+" (other: VECTOR [G]): VECTOR [G] is -- Sum of current vector and other require lower = other.lower upper = other.upper local a, b, c: G do... See next... end... Other features... end

27. Chair of Software Engineering OOSC Summer Semester 2004 27 Constrained genericity (cont’d)  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

28. Chair of Software Engineering OOSC Summer Semester 2004 28 Constrained genericity (cont’d)  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

29. Chair of Software Engineering OOSC Summer Semester 2004 29 The solution  Declare class VECTOR as class VECTOR [G –> NUMERIC] feature... The rest as before... end  Class NUMERIC (from the Kernel Library) provides features infix "+", infix "*" and so on.

30. Chair of Software Engineering OOSC Summer Semester 2004 30 Improving the solution  Make VECTOR itself a descendant of NUMERIC, effecting the corresponding features: class VECTOR [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]]]

31. Chair of Software Engineering OOSC Summer Semester 2004 31 Forcing a type: the problem fs.store ("FILE_NAME")... -- Two years later: fs.retrieve ("FILE_NAME") x := fs.item-- [1] print (x.diagonal)-- [2] But:  If x is declared of type RECTANGLE, [1] is invalid.  If x is declared of type FIGURE, [2] is invalid.

32. Chair of Software Engineering OOSC Summer Semester 2004 32 Assignment attempt f: FIGURE r: RECTANGLE... fs.retrieve ("FILE_NAME") f := fs.item r ?= f if r /= Void then print (r.diagonal) else print ("Too bad.") end

33. Chair of Software Engineering OOSC Summer Semester 2004 33 Assignment attempt (cont’d) x ?= y with x: A  If y is attached to an object whose type conforms to A, perform normal reference assignment.  Otherwise, make x void.

34. Chair of Software Engineering OOSC Summer Semester 2004 34 End of lecture 7