1. Chair of Software Engineering OOSC - Summer Semester 2005 1 Bertrand Meyer Object-Oriented Software Construction Lecture 8: More on inheritance

2. Chair of Software Engineering OOSC - Summer Semester 2005 2 Agenda for today  Constrained genericity  Creating with a specified type  Once routines  Multiple inheritance

3. Chair of Software Engineering OOSC - Summer Semester 2005 3 Agenda for today  Constrained genericity  Creating with a specified type  Once routines  Multiple inheritance

4. Chair of Software Engineering OOSC - Summer Semester 2005 4 Adding two vectors + =uvw i ab c

5. Chair of Software Engineering OOSC - Summer Semester 2005 5 Constrained genericity class VECTOR [G] 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

6. Chair of Software Engineering OOSC - Summer Semester 2005 6 Constrained genericity  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

7. Chair of Software Engineering OOSC - Summer Semester 2005 7 Adding two vectors + =uvw i ab c

8. Chair of Software Engineering OOSC - Summer Semester 2005 8 Constrained genericity: 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.

9. Chair of Software Engineering OOSC - Summer Semester 2005 9 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]]]

10. Chair of Software Engineering OOSC - Summer Semester 2005 10 Agenda for today  Constrained genericity  Creating with a specified type  Once routines  Multiple inheritance

11. Chair of Software Engineering OOSC - Summer Semester 2005 11 Creating with a specified type  To avoid this: a1: A b1: B... create b1.make (...) a1 := b1  Simply use a1: A... create {B} a1.make (...) B A (See factory pattern)

12. Chair of Software Engineering OOSC - Summer Semester 2005 12 Agenda for today  Constrained genericity  Creating with a specified type  Once routines  Multiple inheritance

13. Chair of Software Engineering OOSC - Summer Semester 2005 13 Once routines  If instead of r is do... Instructions... end  you write r is once... Instructions... end  then Instructions will be executed only for the first call by any client during execution. Subsequent calls return immediately.  In the case of a function, subsequent calls return the result computed by the first call.

14. Chair of Software Engineering OOSC - Summer Semester 2005 14 Scheme for shared objects class SHARED_OBJECTS feature error_window: WINDOW is once create Result.make (...) end exit_button: BUTTON is once create Result.make (...) end class MY_APPLICATION_CLASS inherit SHARED_OBJECTS feature r is do error_window.put (my_error_message) end end

15. Chair of Software Engineering OOSC - Summer Semester 2005 15 Agenda for today  Constrained genericity  Creating with a specified type  Once routines  Multiple inheritance

16. Chair of Software Engineering OOSC - Summer Semester 2005 16 Multiple inheritance  Allow a class to have two or more parents.  Examples that come to mind: ASSISTANT inherits from TEACHER and STUDENT. TEACHERSTUDENT ASSISTANT

17. Chair of Software Engineering OOSC - Summer Semester 2005 17 Example: Teaching assistant  This is in fact a case of repeated inheritance: TEACHERSTUDENT ASSISTANT UNIVERSITY_ MEMBER id ?? ????

18. Chair of Software Engineering OOSC - Summer Semester 2005 18 Other examples of multiple inheritance  Combining separate abstractions:  Restaurant, train car  Calculator, watch  Plane, asset

19. Chair of Software Engineering OOSC - Summer Semester 2005 19 Multiple inheritance: Combining abstractions COMPARABLENUMERIC STRINGCOMPLEX INTEGER REAL DOUBLE

20. Chair of Software Engineering OOSC - Summer Semester 2005 20 Multiple inheritance: Composite figures A composite figure Simple figures

21. Chair of Software Engineering OOSC - Summer Semester 2005 21 Defining the notion of composite figure FIGURE LIST [FIGURE] COMPOSITE_ FIGURE display hide rotate move count put remove

22. Chair of Software Engineering OOSC - Summer Semester 2005 22 Composite figures through multiple inheritance FIGURELIST [FIGURE] COMPOSITE_FIGURE OPEN_ FIGURE CLOSED_ FIGURE SEGMENTPOLYLINEPOLYGONELLIPSE RECTANGLE SQUARE CIRCLETRIANGLE perimeter+ perimeter* perimeter++ perimeter+ diagonal

23. Chair of Software Engineering OOSC - Summer Semester 2005 23 A composite figure as a list start item forthafter

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

25. Chair of Software Engineering OOSC - Summer Semester 2005 25 Complex figures  A simpler form of procedures display, move etc. can be obtained through the use of iterators.  We’ll learn to use agents for that purpose.

26. Chair of Software Engineering OOSC - Summer Semester 2005 26 Multiple inheritance INTEGER NUMERIC COMPARABLE REAL DOUBLE STRING MATRIX * *

27. Chair of Software Engineering OOSC - Summer Semester 2005 27 Multiple inheritance from interfaces: limitations  It is often useful to have a mix of abstract and concrete (“effective”) features  Eiffel “deferred” classes permit this.  Not possible in Java and the.NET object model  Java experience shows that programmers resort to various ugly tricks to simulate this… (See John Viega, TOOLS USA 2000)

28. Chair of Software Engineering OOSC - Summer Semester 2005 28 infix "<=" (other: COMPARABLE [G]): BOOLEAN is do Result := Current < other or equal (Current, other) end infix ">=" (other: COMPARABLE [G]) is … infix ">" (other: COMPARABLE [G]) is … … deferred class COMPARABLE [G] feature infix "<" (other: COMPARABLE [G]): BOOLEAN is deferred end end -- class COMPARABLE

29. Chair of Software Engineering OOSC - Summer Semester 2005 29 Multiple inheritance: Name clashes A C foo B

30. Chair of Software Engineering OOSC - Summer Semester 2005 30 Resolving name clashes A C foo B rename foo as fogrename foo as zoo

31. Chair of Software Engineering OOSC - Summer Semester 2005 31 Resolving name clashes class C inherit A rename foo as fog end B rename foo as zoo end feature...

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

33. Chair of Software Engineering OOSC - Summer Semester 2005 33 When is a name clash acceptable?  (Between n features of a class, all with the same name, immediate or inherited.)  They must all have compatible signatures.  If more than one is effective, they must all come from a common ancestor feature under repeated inheritance.

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

35. Chair of Software Engineering OOSC - Summer Semester 2005 35 Feature merging ABC D f* f+f+

36. Chair of Software Engineering OOSC - Summer Semester 2005 36 Feature merging (cont’d) class D inherit A B C feature... end

37. Chair of Software Engineering OOSC - Summer Semester 2005 37 Feature merging: with different names ABC D g* f*h+h+ g f h f

38. Chair of Software Engineering OOSC - Summer Semester 2005 38 Feature merging: with different names class D inherit A rename g as f end B C rename h as f end feature... end

39. Chair of Software Engineering OOSC - Summer Semester 2005 39 Feature merging: effective features a1: Ab1: Bc1: Cd1: D a1.gb1.fc1.hd1.f ABC D g+g+ f+f+ h+h+ g f h f f-f-f-f-

40. Chair of Software Engineering OOSC - Summer Semester 2005 40 Feature merging: effective features class D inherit A rename g as f undefine f end B C rename h as f undefine f end feature... end

41. Chair of Software Engineering OOSC - Summer Semester 2005 41 End of lecture 8