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 8: Inheritance

3. Chair of Software Engineering OOSC Summer Semester 2004 3 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

4. Chair of Software Engineering OOSC Summer Semester 2004 4 Example hierarchy AIRCRAFT * PLANE * COPTER * BOEINGAIRBUS A_320 B_747B_737 B_747_400 * deferred + effected ++ redefined lower_landing_gear* lower_landing_gear++ lower_landing_gear+

5. Chair of Software Engineering OOSC Summer Semester 2004 5 (After Barry W. Boehm) RequirementsDesignCodeDevelopmentAcceptanceOperation test SMALL PROJECTS LARGE PROJECTS

6. Chair of Software Engineering OOSC Summer Semester 2004 6 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. TEACHERSTUDENT TEACHING_ ASSISTANT

7. Chair of Software Engineering OOSC Summer Semester 2004 7 The teaching assistant example  This is in fact a case of repeated inheritance: TEACHERSTUDENT TEACHING_ ASSISTANT UNIVERSITY_ MEMBER id ?? ????

8. Chair of Software Engineering OOSC Summer Semester 2004 8 Common examples of multiple inheritance  Combining separate abstractions:  Restaurant, train car  Calculator, watch  Plane, asset

9. Chair of Software Engineering OOSC Summer Semester 2004 9 Multiple inheritance: Combining abstractions COMPARABLENUMERIC STRINGCOMPLEX INTEGER REAL DOUBLE **

10. Chair of Software Engineering OOSC Summer Semester 2004 10 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

11. Chair of Software Engineering OOSC Summer Semester 2004 11 Multiple inheritance: Composite figures A composite figure Simple figures

12. Chair of Software Engineering OOSC Summer Semester 2004 12 Defining the notion of composite figure FIGURE LIST [FIGURE] COMPOSITE_ FIGURE * display* hide rotate move … count put remove … display +

13. Chair of Software Engineering OOSC Summer Semester 2004 13 Defining the notion of composite figure through multiple inheritance FIGURE LIST [FIGURE] COMPOSITE_ FIGURE * OPEN_ FIGURE CLOSED_ FIGURE SEGMENT POLYLINE POLYGON ELLIPSE RECTANGLE SQUARE CIRCLE TRIANGLE … perimeter+ perimeter* perimeter++ perimeter+ diagonal …

14. Chair of Software Engineering OOSC Summer Semester 2004 14 A composite figure as a list start item forthafter

15. Chair of Software Engineering OOSC Summer Semester 2004 15 Composite figures class COMPOSITE_FIGURE inherit FIGURE redefine display, move, rotate,... end LIST [FIGURE] feature display is -- Display each constituent figure in turn. do from start until after loop item.display forth end end... Similarly for move, rotate etc.... end

16. Chair of Software Engineering OOSC Summer Semester 2004 16 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.

17. Chair of Software Engineering OOSC Summer Semester 2004 17 Name clashes under multiple inheritance A C foo B

18. Chair of Software Engineering OOSC Summer Semester 2004 18 Resolving name clashes A C foo B rename foo as fogrename foo as zoo

19. Chair of Software Engineering OOSC Summer Semester 2004 19 Resolving name clashes (cont’d) class C inherit A rename foo as fog end B rename foo as zoo end feature...

20. Chair of Software Engineering OOSC Summer Semester 2004 20 Results of renaming a1: A b1: B c1: C... c1.fog c1.zoo a1.foo b1.foo Invalid: a1.fog, a1.zoo, b1.zoo, b1.fog, c1.foo

21. Chair of Software Engineering OOSC Summer Semester 2004 21 Another application of renaming  Provide locally better adapted terminology.  Example: child (TREE); subwindow (WINDOW).

22. Chair of Software Engineering OOSC Summer Semester 2004 22 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

23. Chair of Software Engineering OOSC Summer Semester 2004 23 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?

24. Chair of Software Engineering OOSC Summer Semester 2004 24 Deferred classes deferred class FIGURE feature move (v: VECTOR) is deferred end rotate (a: ANGLE; p: POINT) is deferred end... display, hide,... end Not permitted: create f...

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++

26. Chair of Software Engineering OOSC Summer Semester 2004 26 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).

27. Chair of Software Engineering OOSC Summer Semester 2004 27 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).

28. Chair of Software Engineering OOSC Summer Semester 2004 28 Table variants TABLE * SEQUENTIAL_ TABLE * LINKED_ TABLE + ARRAY_ TABLE + FILE_ TABLE +

29. Chair of Software Engineering OOSC Summer Semester 2004 29 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? do from start until after or else equal (item, x) loop forth end Result := not after end

30. Chair of Software Engineering OOSC Summer Semester 2004 30 SEQUENTIAL_TABLE (cont’d) forth is -- Move cursor to the next position. require not after deferred ensure position = old position + 1 end start is -- Move cursor to the first position. deferred ensure empty or else position = 1 end

31. Chair of Software Engineering OOSC Summer Semester 2004 31 SEQUENTIAL_TABLE (end) position: INTEGER is deferred end... empty, found, after,... invariant 0 <= position position <= size + 1 empty implies (after or before) end

32. Chair of Software Engineering OOSC Summer Semester 2004 32 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*

33. Chair of Software Engineering OOSC Summer Semester 2004 33 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*

34. Chair of Software Engineering OOSC Summer Semester 2004 34 Implementation variants Array Linked list File startforthafteritem (x) c := first_cell rewind i := 1 c := c.right i := i + 1 readend_of_file c := Void f c.item i > countt [i]

35. Chair of Software Engineering OOSC Summer Semester 2004 35 End of lecture 8