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 13: Advanced inheritance mechanisms

3. Chair of Software Engineering OOSC - Summer Semester 2004 3 Deferred classes deferred class STACK [G] feature put (x: G) is -- Push x on top of stack. require not full deferred ensure item = x not empty end

4. Chair of Software Engineering OOSC - Summer Semester 2004 4 The STACK class (cont’d) remove is -- Pop top element of stack. require not empty deferred ensure not full count = old count – 1 end

5. Chair of Software Engineering OOSC - Summer Semester 2004 5 The STACK class (cont’d) full: BOOLEAN is -- Is there no room place for new items? deferred end empty: BOOLEAN is -- Is there no item? deferred end count: BOOLEAN is -- Number of items on stack deferred ensure Result >= 0 end

6. Chair of Software Engineering OOSC - Summer Semester 2004 6 The STACK class (cont’d) -- Not all features need be deferred! replace (x: G) is -- Replace top element of stack by x. require not empty do remove put (x) ensure not empty item = x count = old count end invariant not (full and empty) end

7. Chair of Software Engineering OOSC - Summer Semester 2004 7 Applications of deferred classes  Taxonomy  Library organization  Capturing common abstractions  Capturing common behaviors  “Don’t call us, we’ll call you”  Analysis  High-level architecture and design

8. Chair of Software Engineering OOSC - Summer Semester 2004 8 EiffelBase: Container structures CONTAINER * BOX * COLLECTION * TRAVERSABLE * FINITE * INFINITE * BOUNDED * UNBOUNDED * COUNTABLE * RESIZABLE * BAG * SET * HIERARCHICAL * LINEAR * TABLE * ACTIVE * INTEGER_ INTERVAL * BILINEAR * INDEXABLE * CURSOR_ STRUCTURE * DISPENSER * SEQUENCE * ARRAYSTRINGHASH_TABLESTACK * QUEUE * … …

9. Chair of Software Engineering OOSC - Summer Semester 2004 9 deferred class VAT inherit TANK feature in_valve, out_valve: VALVE fill is -- Fill the vat. require in_valve.open out_valve.closed deferred ensure in_valve.closed out_valve.closed is_full end empty, is_full, is_empty, gauge, maximum,... [Other features]... invariant is_full = (gauge >= 0.97 * maximum) and (gauge <= 1.03 * maximum) end Object-oriented analysis

10. Chair of Software Engineering OOSC - Summer Semester 2004 10 Indirect and direct repeated inheritance A B C D A D

11. Chair of Software Engineering OOSC - Summer Semester 2004 11 Repeated inheritance  Assume class TAXPAYER with attributes age: INTEGER address: STRING bank_account: ACCOUNT tax_id: INTEGER  and routines such as pass_birthday is do age := age + 1 end pay_taxes is... deposit_to_account (sum: INTEGER) is... TAXPAYER address tax_id pass_birthday age pay_taxes

12. Chair of Software Engineering OOSC - Summer Semester 2004 12 Repeated inheritance (cont’d)  Heirs may include SWISS_TAXPAYER and US_TAXPAYER. TAXPAYER address tax_id age pay_taxes pass_birthday US_ TAXPAYER SWISS_ TAXPAYER

13. Chair of Software Engineering OOSC - Summer Semester 2004 13 Repeated inheritance (cont’d)  The two above classes may in turn have a common heir: SWISS_US_TAXPAYER. TAXPAYER address tax_id pay_taxes pass_birthday US_ TAXPAYER SWISS_ TAXPAYER SWISS_US_ TAXPAYER

14. Chair of Software Engineering OOSC - Summer Semester 2004 14 Repeated inheritance issues  What happens with features inherited twice from the common ancestor TAXPAYER, such as address, age, tax_id, pass_birthday?

15. Chair of Software Engineering OOSC - Summer Semester 2004 15 The inheritance clause inherit SWISS_TAXPAYER rename address as swiss_address, tax_id as swiss_tax_id, pay_taxes as pay_swiss_taxes, bank_account as swiss_bank_account, deposit_to_account as deposit_to_swiss_account,... end US_TAXPAYER rename address as us_address, tax_id as us_tax_id, pay_taxes as pay_us_taxes, bank_account as us_bank_account, deposit_to_account as deposit_to_us_account,... end

16. Chair of Software Engineering OOSC - Summer Semester 2004 16 Sharing and replication  Features such as age and birthday, not renamed along any of the inheritance paths, will be shared.  Features such as tax_id, inherited under different names, will be replicated. TAXPAYER address tax_id pay_taxes pass_birthday US_ TAXPAYER SWISS_ TAXPAYER SWISS_US_ TAXPAYER address us_address tax_id us_tax_id pay_taxes pay_us_taxes address swiss_address tax_id swiss_tax_id pay_taxes pay_swiss_taxes

17. Chair of Software Engineering OOSC - Summer Semester 2004 17 The need for select  Assume there is a redefinition somewhere along the way: TAXPAYER address US_ TAXPAYER SWISS_ TAXPAYER SWISS_US_ TAXPAYER address++ address us_addressaddress swiss_address

18. Chair of Software Engineering OOSC - Summer Semester 2004 18 The need for select (cont’d)  A potential ambiguity arises because of polymorphism and dynamic binding: t: TAXPAYER s: SWISS_TAXPAYER u: US_TAXPAYER su: SWISS_US_TAXPAYER if... then t := s else t := su end... print (t.address)

19. Chair of Software Engineering OOSC - Summer Semester 2004 19 Removing the ambiguity class SWISS_US_TAXPAYER inherit SWISS_TAXPAYER rename address as swiss_address, tax_id as swiss_tax_id, pay_taxes as pay_swiss_taxes, bank_account as swiss_bank_account, deposit_to_account as deposit_to_swiss_account,... select swiss_address, swiss_tax_id, pay_swiss_taxes, swiss_bank_account, deposit_to_swiss_account end US_TAXPAYER rename address as us_address, tax_id as us_tax_id,... end

20. Chair of Software Engineering OOSC - Summer Semester 2004 20 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 (...) A BC

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

22. Chair of Software Engineering OOSC - Summer Semester 2004 22 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... end class MY_APPLICATION_CLASS inherit SHARED_OBJECTS feature r is do error_window.put (my_error_message) end... end

23. Chair of Software Engineering OOSC - Summer Semester 2004 23 Undefining a feature deferred class B inherit A undefine f end feature... end

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

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

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

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

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

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

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

31. Chair of Software Engineering OOSC - Summer Semester 2004 31 Feature adaptation clauses  rename  export  undefine  redefine  select

32. Chair of Software Engineering OOSC - Summer Semester 2004 32 Export adaptation class B inherit A export {ANY} all {NONE} h {A, B, C, D} i, j, k end feature...

33. Chair of Software Engineering OOSC - Summer Semester 2004 33 End of lecture 13