1 / 38

Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer

Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer. Exercise Session 10. Today. Multiple inheritance. Combining abstractions. Given the classes TRAIN_CAR , RESTAURANT how would you implement a DINER ?. Inheritance is never the only way.

casimir-lel
Download Presentation

Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Einführung in die ProgrammierungIntroduction to ProgrammingProf. Dr. Bertrand Meyer Exercise Session 10

  2. Today • Multiple inheritance

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

  4. Inheritance is never the only way • Given the classes • TRAIN_CAR, RESTAURANT • how would you implement a DINER? • You could have an attribute in TRAIN_CAR train_service: SERVICE • Then have RESTAURANT inherit from SERVICE • This is flexible if the kind of service may change to a type that is unrelated to TRAIN_CAR • Changes in TRAIN_CAR do not affect SERVICE easily

  5. Examples of multiple inheritance Hands-On • Combining separate abstractions: • Restaurant, train car • Calculator, watch • Other examples?

  6. Examples of multiple inheritance Hands-On • Combining separate abstractions: • Restaurant, train car • Calculator, watch • Other examples? • Teacher, student • Home, vehicle

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

  8. Composite figures

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

  10. Defining the notion of composite figure center display hide rotate move … V_LIST [FIGURE] FIGURE count put remove … COMPOSITE_FIGURE

  11. In the overall structure V_LIST [FIGURE] FIGURE OPEN_FIGURE CLOSED_FIGURE perimeter* SEGMENT POLYLINE POLYGON ELLIPSE perimeter+ perimeter+ diagonal COMPOSITE_FIGURE RECTANGLE CIRCLE perimeter++ perimeter++ TRIANGLE SQUARE perimeter++

  12. A composite figure as a list before after item forth Cursor

  13. Composite figures • class COMPOSITE_FIGUREinherit • FIGURE • V_LIST [FIGURE] • feature • display • -- Display each constituent figure in turn.do from startuntil afterloop • item.display • forthendend • ... Similarly for move, rotate etc. ... • end Requires dynamic binding

  14. An alternative solution: the composite pattern LIST [FIGURE] FIGURE OPEN_FIGURE CLOSED_FIGURE perimeter* SEGMENT POLYLINE POLYGON ELLIPSE perimeter+ perimeter+ diagonal COMPOSITE_FIGURE RECTANGLE CIRCLE perimeter++ perimeter++ TRIANGLE SQUARE perimeter++ figure_list

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

  16. B A f C ? Multiple inheritance: Name clashes Hands-On f

  17. B A f renamefasA_f C A_f, f Resolving name clashes Hands-On f

  18. B A f f renamefasA_f C A_f, f Consequences of renaming Hands-On • Valid or invalid? • a1: A • b1: B • c1: C • ... • c1.f • a1.A_f • c1.A_f • b1.f • b1.A_f Valid Invalid Valid Valid Invalid

  19. 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) indirect repeated inheritance direct repeated inheritance

  20. Feature merging f + A B C f* f* D *Deferred +Effective

  21. g h f f Feature merging: with different names class D inherit Arename gasf end B Crename hasf end feature ... end h + g* A B C f* D *Deferred +Effective Renaming

  22. Feature merging: effective features f + f + A B C f + f -- f -- D *Deferred +Effective -- Undefine

  23. Undefinition deferredclass T inherit S undefinevend feature ... end

  24. Merging through undefinition f + f + f + A B C class D inherit Aundefinef end B Cundefinefend feature ... end f-- f-- D *Deferred +Effective -- Undefine

  25. Merging effective features with different names h g f f f + C h + g + B A class D inherit A undefinefend B rename gasf undefinef end C rename hasf end feature ... end f -- f -- D

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

  27. Exercise: All-in-one-device Hands-On SCANNER PRINTER FAX ALL_IN_ONE_DEVICE

  28. Exercise: All-in-one-device Hands-On classPRINTER feature print_page -- Print a page. do print ("Printer prints a page...") end switch_on -- Switch from ‘off‘ to ‘on‘ do print ("Printer switched on...") end end classFAX feature send -- Send a page over the phone net. do print (“Fax sends a page...") end start -- Switch from ‘off‘ to ‘on‘ do print (“Fax switched on...") end end classSCANNER feature scan_page -- Scan a page. do print (“Scanner scans a page...") end switch_on -- Switch from ‘off‘ to ‘on‘ do print (“Scanner switched on...") end send -- Send data to PC. do print (“Scanner sends data...") end end

  29. Exercise: All-in-one-device Hands-On SCANNER PRINTER FAX ALL_IN_ONE_DEVICE class ALL_IN_ONE_DEVICE inherit ... end How to resolve the name clashes? • switch_on • send

  30. Exercise: All-in-one-device Hands-On classALL_IN_ONE_DEVICE inherit PRINTER rename switch_on as start undefine start end SCANNER rename switch_on as start, send as send_data end FAX rename send as send_message undefine start end feature ... end

  31. Valid or invalid? Hands-On classALL_IN_ONE_DEVICE inherit PRINTER rename switch_on as start undefine start end SCANNER rename switch_on as start, send as send_data end FAX rename send as send_message undefine start end feature ... end • s: SCANNER • f: FAX • a: ALL_IN_ONE_DEVICE • a.switch_on • a.print_page • f.send_message • s.switch_on • f.send • a.send Invalid Valid Invalid Valid Valid Invalid

  32. A special case of multiple inheritance UNIVERSITY_MEMBER id TEACHER STUDENT ?? ?? ASSISTANT ???? This is a case of repeated inheritance

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

  34. Multiple is also repeated inheritance • A typical case: copy is_equal ANY copy++ is_equal++ C LIST copyC_copy D is_equalC_is_equal ??

  35. 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. f g A gg_c gg_b C B D

  36. The need for select A potential ambiguity arises because of polymorphism and dynamic binding: a1: ANY d1: D … a1 := d1a1.copy(…) copy • is_equal ANY C LIST copy ++ • is_equal ++ copyC_copy is_equalC_is_equal D

  37. Removing the ambiguity class D inheritV_LIST [T ] select copy, is_equal end CrenamecopyasC_copy, is_equalasC_is_equal, ...end

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

More Related