1 ObjectOriented Software Construction Bertrand Meyer Chair of
1 Object-Oriented Software Construction Bertrand Meyer Chair of Software Engineering OOSC - Summer Semester 2004
2 Lecture 13: Advanced inheritance mechanisms Chair of Software Engineering OOSC - Summer Semester 2004
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 Chair of Software Engineering OOSC - Summer Semester 2004 3
The STACK class (cont’d) remove is -- Pop top element of stack. require not empty deferred ensure not full count = old count – 1 end Chair of Software Engineering OOSC - Summer Semester 2004 4
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 Chair of Software Engineering OOSC - Summer Semester 2004 5
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 Chair of Software Engineering OOSC - Summer Semester 2004 6
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 Chair of Software Engineering OOSC - Summer Semester 2004 7
Eiffel. Base: Container structures 8 * CONTAINER * BOX * COLLECTION * FINITE * INFINITE * BOUNDED * UNBOUNDED * COUNTABLE * TRAVERSABLE * BAG * SET * TABLE * ACTIVE * HIERARCHICAL * INTEGER_ INTERVAL … * RESIZABLE ARRAY * INDEXABLE STRING Chair of Software Engineering * CURSOR_ STRUCTURE HASH_TABLE * DISPENSER * STACK OOSC - Summer Semester 2004 * LINEAR * BILINEAR … * SEQUENCE * QUEUE
Object-oriented analysis deferred class VAT inherit TANK feature in_valve, out_valve: VALVE fill is require deferred ensure end -- Fill the vat. in_valve. open out_valve. closed in_valve. closed out_valve. closed is_full empty, is_full, is_empty, gauge, maximum, . . . [Other features]. . . invariant is_full = (gauge >= 0. 97 * maximum) and (gauge <= 1. 03 * maximum) end Chair of Software Engineering OOSC - Summer Semester 2004 9
Indirect and direct repeated inheritance A A C B D D Chair of Software Engineering OOSC - Summer Semester 2004 10
Repeated inheritance 11 § 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 age TAXPAYER address tax_id pass_birthday pay_taxes is. . . deposit_to_account (sum: INTEGER) is. . . Chair of Software Engineering OOSC - Summer Semester 2004
Repeated inheritance (cont’d) § Heirs may include SWISS_TAXPAYER and US_TAXPAYER. age TAXPAYER address tax_id pass_birthday pay_taxes US_ TAXPAYER Chair of Software Engineering SWISS_ TAXPAYER OOSC - Summer Semester 2004 12
Repeated inheritance (cont’d) § The two above classes may in turn have a common heir: SWISS_US_TAXPAYER address tax_id pass_birthday pay_taxes US_ TAXPAYER SWISS_US_ TAXPAYER Chair of Software Engineering OOSC - Summer Semester 2004 13
Repeated inheritance issues § What happens with features inherited twice from the common ancestor TAXPAYER, such as address, age, tax_id, pass_birthday? Chair of Software Engineering OOSC - Summer Semester 2004 14
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 end Chair of Software Engineering 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, . . . OOSC - Summer Semester 2004 15
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 US_ TAXPAYER address us_address tax_id us_tax_id pay_taxes pay_us_taxes Chair of Software Engineering address tax_id pass_birthday pay_taxes SWISS_ TAXPAYER SWISS_US_ TAXPAYER OOSC - Summer Semester 2004 address swiss_address tax_id swiss_tax_id pay_taxes pay_swiss_taxes 16
The need for select 17 § Assume there is a redefinition somewhere along the way: TAXPAYER address++ address SWISS_ address++ TAXPAYER US_ TAXPAYER us_address Chair of Software Engineering SWISS_US_ TAXPAYER address OOSC - Summer Semester 2004 swiss_address
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) Chair of Software Engineering OOSC - Summer Semester 2004 18
Removing the ambiguity class SWISS_US_TAXPAYER inherit SWISS_TAXPAYER rename select end US_TAXPAYER rename end Chair of Software Engineering 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, . . . swiss_address, swiss_tax_id, pay_swiss_taxes, swiss_bank_account, deposit_to_swiss_account address as us_address, tax_id as us_tax_id, . . . OOSC - Summer Semester 2004 19
Creating with a specified type 20 § To avoid this: A a 1: A b 1: B. . . create b 1. make (. . . ) a 1 : = b 1 B § Simply use a 1: A. . . create {B} a 1. make (. . . ) Chair of Software Engineering OOSC - Summer Semester 2004 C
Once routines § If instead of r is do end . . . Instructions. . . § you write r is once end . . . Instructions. . . § 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. Chair of Software Engineering OOSC - Summer Semester 2004 21
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 . . . end do end Chair of Software Engineering error_window. put (my_error_message) OOSC - Summer Semester 2004 22
Undefining a feature deferred class B inherit A undefine f end feature. . . end Chair of Software Engineering OOSC - Summer Semester 2004 23
Feature merging f* A f* 24 B D Chair of Software Engineering OOSC - Summer Semester 2004 f+ C
Feature merging (cont’d) class D inherit A B C feature. . . end Chair of Software Engineering OOSC - Summer Semester 2004 25
Feature merging: with different names g* A f* g Chair of Software Engineering f B D OOSC - Summer Semester 2004 h+ h f C 26
Feature merging: with different names class D inherit A rename g as f end B C rename h as f end feature. . . end Chair of Software Engineering OOSC - Summer Semester 2004 27
Feature merging: effective features g* A f* g f- a 1: A a 1. g Chair of Software Engineering b 1: B b 1. f f B D c 1: C c 1. h OOSC - Summer Semester 2004 h+ h f- f d 1: D d 1. f C 28
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 . . . Chair of Software Engineering OOSC - Summer Semester 2004 29
When is a name clash acceptable? 30 § (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. Chair of Software Engineering OOSC - Summer Semester 2004
Feature adaptation clauses § § § rename export undefine redefine select Chair of Software Engineering OOSC - Summer Semester 2004 31
Export adaptation class B inherit A export {ANY} all {NONE} h {A, B, C, D} i, j, k end feature. . . Chair of Software Engineering OOSC - Summer Semester 2004 32
33 End of lecture 13 Chair of Software Engineering OOSC - Summer Semester 2004
- Slides: 33