1. Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 20: Multiple inheritance

2. 2 Combining abstractions Given the classes  TRAIN_CAR, RESTAURANT how would you implement a DINER?

3. 3 Examples of multiple inheritance Combining separate abstractions:  Restaurant, train car  Calculator, watch  Plane, asset  Home, vehicle  Tram, bus

4. 4 Warning Forget all you have heard! Multiple inheritance is not the works of the devil Multiple inheritance is not bad for your teeth (Even though Microsoft Word apparently does not like it: )

5. 5 This is repeated, not just multiple inheritance A D B C A D Not the basic case! (Although it does arise often; why?)

6. 6 Another warning The language part of this lecture are Eiffel-oriented Java and C# mechanisms (single inheritance from classes, multiple inheritance from interfaces) will also be discussed C++ also has multiple inheritance, but I will not try to describe it

7. 7 Composite figures

8. 8 Multiple inheritance: Composite figures A composite figure Simple figures

9. 9 Defining the notion of composite figure COMPOSITE_ FIGURE center display hide rotate move … count put remove … FIGURE LIST [FIGURE ]

10. 10 In the overall structure COMPOSITE_ FIGURE FIGURE LIST [FIGURE ] OPEN_ FIGURE CLOSED_ FIGURE SEGMENTPOLYLINEPOLYGON ELLIPSE RECTANGLE SQUARE CIRCLE TRIANGLE perimeter + perimeter* perimeter ++ diagonal perimeter ++ perimeter +

11. 11 A composite figure as a list Cursor item forth after

12. 12 Composite figures class COMPOSITE_FIGURE inherit FIGURE LIST [FIGURE] feature display -- Display each constituent figure in turn. do from start until after loop item. display forth end end... Similarly for move, rotate etc.... end Requires dynamic binding

13. 13 Going one level of abstraction higher A simpler form of procedures display, move etc. can be obtained through the use of iterators Use agents for that purpose See in a couple of weeks (but you are welcome to read the chapter in advance)

14. 14 Multiple inheritance: Combining abstractions COMPARABLE NUMERIC STRING COMPLEX INTEGER REAL, >=, … +, –, , / … (total order relation) (commutative ring)

15. 15 The Java-C# solution No multiple inheritance for classes “Interfaces”: specification only (but no contracts)  Similar to completely deferred classes (with no effective feature) A class may inherit from:  At most one class  Any number of interfaces

16. 16 Multiple inheritance: Combining abstractions COMPARABLE NUMERIC STRING COMPLEX INTEGER REAL, >=, … +, –, , / … (total order relation) (commutative ring)

17. 17 How do we write COMPARABLE? deferred class COMPARABLE [G ] feature end less alias "<" (x : COMPARABLE [G ]): BOOLEAN deferred end less_equal alias "<=" (x : COMPARABLE [G ]): BOOLEAN do Result := (Current < x or (Current = x)) end greater alias " >" (x : COMPARABLE [G ]): BOOLEAN do Result := (x < Current) end greater_equal alias " >=" (x : COMPARABLE [G ]): BOOLEAN do Result := (x <= Current) end

18. 18 Lessons from this example Typical example of program with holes We need the full spectrum from fully abstract (fully deferred) to fully implemented classes Multiple inheritance is there to help us combine abstractions

19. 19 A common Eiffel library idiom class ARRAYED_LIST [G ] inherit LIST [G ] ARRAY [G ] feature … Implement LIST features using ARRAY features … end For example: i_th (i : INTEGER ): G -- Element of index `i’. do Result := item (i ) end Feature of ARRAY

20. 20 Could use delegation instead class ARRAYED_LIST [G ] inherit LIST [G ] feature rep : ARRAY [G ] … Implement LIST features using ARRAY features applied to rep … end For example: i_th (i : INTEGER ): G -- Element of index `i’. do Result := rep item (i) end

21. 21 Non-conforming inheritance class ARRAYED_LIST [G ] inherit LIST [G ] ARRAY [G ] feature … Implement LIST features using ARRAY features … end inherit {NONE } ARRAYLIST ARRAYED _LIST Non-conforming inheritance

22. 22 Multiple inheritance: Name clashes f C f A B ?

23. 23 Resolving name clashes f rename f as A_f C f A B A_f, f

24. 24 Consequences of renaming a1 : A b1 : B c1 : C... c1. f c1. A_f a1. f b1. f rename f as A_f C f A B A_f, f f Invalid:  a1. A_f  b1. A_f

25. 25 Are all name clashes bad? A name clash must be removed unless it is:  Under repeated inheritance (i.e. not a real clash)  Between features of which at most one is effective (i.e. others are deferred)

26. 26 Another application of renaming Provide locally better adapted terminology. Example: child (TREE ); subwindow (WINDOW)

27. 27 Renaming to improve feature terminology ‘ ‘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] rename parent as superwindow, children as subwindows, add_child as add_subwindow … end feature... end BUT: see style rules about uniformity of feature names

28. 28 Feature merging ABC D f + f *f * f *f *  Deferred + Effective

29. 29 Feature merging: with different names ABC D h + g *g * f *f *  Deferred + Effective Renaming g f h f class D inherit A rename g as f end B C rename h as f end feature... end

30. 30 Feature merging: effective features ABC D f +  Deferred + Effective -- Undefine f --

31. 31 Undefinition deferred class T inherit S undefine v end feature... end

32. 32 Merging through undefinition class D inherit A undefine f end B C undefine f end feature... end ABC D f + f --  Deferred + Effective -- Undefine

33. 33 Merging effective features with different names A B C D h + f + g + f -- class D inherit A undefine f end B rename g as f undefine f end C rename h as f end feature... end h f g f

34. 34 Acceptable name clashes If inherited features have all the same names, there is no harmful name clash if:  They all have compatible signatures  At most one of them is effective Semantics of such a case:  Merge all features into one  If there is an effective feature, it imposes its implementation

35. 35 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-

36. 36 A special case of multiple inheritance Allow a class to have two or more parents. Examples that come to mind: ASSISTANT inherits from TEACHER and STUDENT. TEACHER STUDENT ASSISTANT UNIVERSITY _MEMBER id This is a case of repeated inheritance ?? ????

37. 37 Indirect and direct repeated inheritance A D B C A D

38. 38 Multiple is also repeated inheritance A typical case: copy ++ is_equal ++ copy is_equal ?? copy C_copy is_equal C_is_equal C LIST D ANY

39. 39 Acceptable name clashes If inherited features have all the same names, there is no harmful name clash if:  They all have compatible signatures  At most one of them is effective Semantics of such a case:  Merge all features into one  If there is an effective feature, it imposes its implementation

40. 40 Sharing and replication Features such as f, not renamed along any of the inheritance paths, will be shared. Features such as g, inherited under different names, will be replicated. A B C D fgfg g g_b g g_c

41. 41 The need for select A potential ambiguity arises because of polymorphism and dynamic binding: a1 : ANY d1 : D … a1 := d1 a. copy (…) copy ++ is_equal ++ copy C_copy is_equal C_is_equal C LIST D copy is_equal ANY

42. 42 Removing the ambiguity class D inherit LIST [T ] select copy, is_equal end C rename copy as C_copy, is_equal as C_is_equal,... end

43. 43 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.

44. 44 What we have seen A number of games one can play with inheritance:  Multiple inheritance  Feature merging  Repeated inheritance