Object-Oriented Software Construction

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

2. Lecture 8: Inheritance 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 OOSC Summer Semester 2004

4. Example hierarchy * deferred * + effected AIRCRAFT ++ redefined * * PLANE COPTER lower_landing_gear* BOEING AIRBUS lower_landing_gear+ A_320 B_737 B_747 lower_landing_gear++ B_747_400 OOSC Summer Semester 2004

5. (After Barry W. Boehm) LARGE PROJECTS SMALL PROJECTS Requirements Design Code Development Acceptance Operation test test 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. TEACHER STUDENT TEACHING_ASSISTANT OOSC Summer Semester 2004

7. The teaching assistant example • This is in fact a case of repeated inheritance: id UNIVERSITY_MEMBER ?? ?? TEACHER STUDENT TEACHING_ASSISTANT ???? OOSC Summer Semester 2004

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

9. Multiple inheritance: Combining abstractions * * COMPARABLE NUMERIC INTEGER REAL STRING COMPLEX DOUBLE 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... classWINDOWinherit RECTANGLE TREE [WINDOW] feature ...end OOSC Summer Semester 2004

11. Multiple inheritance: Composite figures Simple figures A composite figure OOSC Summer Semester 2004

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

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

14. A composite figure as a list item start forth after OOSC Summer Semester 2004

15. Composite figures classCOMPOSITE_FIGUREinherit FIGUREredefinedisplay, move, rotate, ... end LIST [FIGURE] feature displayis-- Display each constituent figure in turn.do fromstart untilafterloopitem.displayforthendend ... Similarly for move, rotate etc. ... end 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. OOSC Summer Semester 2004

17. Name clashes under multiple inheritance A B foo foo C OOSC Summer Semester 2004

18. Resolving name clashes A B foo foo renamefooasfog renamefooaszoo C OOSC Summer Semester 2004

19. Resolving name clashes (cont’d) classCinherit A rename fooasfog end B rename fooaszoo end feature ... 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 OOSC Summer Semester 2004

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

22. The marriage of convenience classARRAYED_STACK [G] inherit STACK [G] ARRAY [G] feature ... end classLINKED_STACK [G] inherit STACK [G] LINKED_LIST [G] feature ...end OOSC Summer Semester 2004

23. The need for deferred classes • In the scheme seen earlier: f: FIGURE; c: CIRCLE; p: POLYGON ... createc.make (...); createp.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? OOSC Summer Semester 2004

24. Deferred classes deferred classFIGUREfeature move (v: VECTOR) is deferred end rotate (a: ANGLE; p: POINT) is deferred end ... display, hide, ... end Not permitted: createf ... OOSC Summer Semester 2004

25. Example hierarchy extent* display* barycenter* * rotate* … FIGURE … * * OPEN_ FIGURE CLOSED_ FIGURE perimeter* perimeter+ perimeter+ SEGMENT POLYLINE POLYGON ELLIPSE diagonal perimeter++ ... ... TRIANGLE RECTANGLE CIRCLE perimeter++ perimeter++ SQUARE 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). 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). OOSC Summer Semester 2004

28. Table variants * TABLE * SEQUENTIAL_TABLE + + + ARRAY_TABLE LINKED_TABLE FILE_ TABLE OOSC Summer Semester 2004

29. Don’t call us, we’ll call you deferred classSEQUENTIAL_TABLE [G] inherit TABLE [G] feature has (x: G): BOOLEANis-- Doesxappear in table?do from start until afteror elseequal (item, x) loopforthendResult := notafterend OOSC Summer Semester 2004

30. SEQUENTIAL_TABLE (cont’d) forthis -- Move cursor to the next position. require notafterdeferred ensureposition = oldposition + 1end startis -- Move cursor to the first position. deferred ensureemptyor elseposition = 1end OOSC Summer Semester 2004

31. SEQUENTIAL_TABLE (end) position: INTEGERis deferred end ... empty, found, after, ... invariant 0 <= position position <= size + 1 emptyimplies (afterorbefore) end OOSC Summer Semester 2004

32. Descendant implementations has* * TABLE after* * forth* SEQUENTIAL_TABLE has+ item* start* + + + ARRAY_TABLE LINKED_TABLE FILE_ TABLE after+ after+ after+ forth+ forth+ forth+ item+ item+ item+ start+ start+ start+ OOSC Summer Semester 2004

33. Descendant implementations (cont’d) after* * forth* SEQUENTIAL_TABLE item* start* has+ + + + ARRAY_TABLE LINKED_TABLE FILE_ TABLE after+ after+ after+ forth+ forth+ forth+ item+ item+ item+ start+ start+ start+ OOSC Summer Semester 2004

34. Implementation variants start forth after item (x) Array i := 1 i := i + 1 i > count t [i] Linked list c := first_cell c := c.right c := Void c.item File rewind read end_of_file f OOSC Summer Semester 2004

35. End of lecture 8 OOSC Summer Semester 2004