Introduction to Programming. Lecture 20: More about inheritance. Multiple inheritance. Composite figures. Bertrand Meyer

Transcription

1 1 2 Introduction to Programming ertrand Meyer Lecture 20: More about ance Last revised 10 January 2004 Multiple ance 3 Simpler examples of multiple ance 4 llow a class to have two or more parents. UNIVERSITY_ MEMER id ombining separate abstractions: Examples that come to mind: SSISTNT s from TEHER and STUENT.?? TEHER STUENT?? Restaurant, train car alculator, watch Plane, asset Home, vehicle This is in fact a case of repeated ance SSISTNT???? Multiple ance: ombining abstractions 5 omposite figures 6 OMPRLE NUMERI INTEGER REL STRING OULE OMPLEX 1

2 Multiple ance: omposite figures 7 efining the notion of composite figure 8 Simple figures display hide rotate move OMPOSITE_ LIST [] count put remove composite figure omposite figures through multiple ance 9 composite figure as a list 10 LIST [] OPEN_ LOSE_ perimeter* OMPOSITE_ SEGMENT POLYLINE POLYGON ELLIPSE perimeter+ perimeter+ diagonal TRINGLE RETNGLE IRLE perimeter++ perimeter++ start item forth after SQURE perimeter++ omposite figures 11 omplex figures 12 class OMPOSITE_ redefine display, move, rotate, LIST [] display is -- isplay each constituent figure in turn. from start until after loop item.display forth Similarly for move, rotate etc. simpler form of procedures display, move etc. can be obtained through the use of iterators. We ll learn to use agents for that purpose. 2

3 n ance hierarchy 13 The role of deferred classes 14 eferred class: STK Express abstract concepts indepently of implementation Effective classes: LINKE_STK, RRYE_STK etc. ISPENSER* Express common elements of various implementations *: deferred STK* QUEUE* RRYE_STK LINKE_STK RRYE_QUEUE Terminology: Effective = non-deferred (i.e. fully implemented) deferred 15 Mixing deferred and effective s16 In e.g. LIST: In the same class Effective! forth is require not after deferred ensure index = old index + 1 search (x: G) is -- Move to first position after current -- where x appears, or after if none. from until after or else item = x loop forth eferred! Programs with holes on t call us, we ll call you! 17 pplications of deferred classes 18 powerful form of reuse: nalysis and design, top-wn The reusable element defines a general scheme Taxonomy Specific cases fill in the holes in that scheme apturing common behaviors ombine reuse with adaptation 3

4 deferred 19 deferred 20 In e.g. LIST: forth is require not after deferred ensure index = index + 1 require not after eferred classes in Eiffelase 21 Java and.net solution 22 ONTINER * OX * OLLETION * TRVERSLE * FINITE * INFINITE * G * SET * HIERRHIL * LINER * Single ance only for classes Multiple ance from interfaces OUNE * UNOUNE * OUNTLE * RESIZLE * INEXLE * URSOR_ TLE * TIVE * INTEGER_ * ILINER * INTERVL * ISPENSER * SEQUENE * STRUTURE n interface is like a fully deferred class, with no implementations ( clauses), no attributes (and also no contracts) RRY STRING HSH_TLE STK * QUEUE * *: deferred Multiple ance: ombining abstractions OMPRLE NUMERI INTEGER REL 23 deferred class OMPRLE [G] infix "<" (other: OMPRLE [G]): OOLEN is deferred infix "<=" (other: OMPRLE [G]): OOLEN is Result := urrent < other or equal (urrent, other) 24 STRING OULE OMPLEX infix ">=" (other: OMPRLE [G]) is infix ">" (other: OMPRLE [G]) is 4

5 Lessons from this example 25 Multiple ance: Name clashes 26 We need the full spectrum from fully abstract (fully deferred) to fully implemented classes Multiple ance is there to help us combine abstractions foo foo Resolving name clashes 27 Resolving name clashes 28 foo foo as fog foo foo as zoo class foo as fog foo as zoo Results of renaming 29 Feature merging 30 a1: b1: c1: c1.fog c1.zoo a1.foo b1.foo f* f* f+ Invalid: a1.fog, a1.zoo, b1.zoo, b1.fog, c1.foo 5

6 cceptable name clashes 31 Feature merging: with different names 32 If ed s have all the same names, there is no harmful name clash if: g* f* h+ They all have compatible signatures t most one of them is effective Semantics of such a case: Merge all s into one If there is an effective, it imposes its implementation g f h f Feature merging: with different names 33 Feature merging: effective s 34 class g as f g+ f+ h+ h as f Undefining a 35 Feature merging: effective s 36 deferred class undefine f class g as f undefine f h as f undefine f 6

7 Feature merging: effective s 37 Indirect and direct repeated ance 38 g+ f+ h+ g f h f f- f- a1: b1: c1: d1: a1.g b1.f c1.h d1.f Multiple is also repeated ance 39 Repeated ance 40 typical case: copy++ is_equal++ NY?? copy is_equal ssume class with attributes age: INTEGER address: STRING bank_account: OUNT tax_id: INTEGER and routines such as pass_birthday is age := age + 1 address age tax_id pass_birthday pay_taxes pay_taxes is deposit_to_account (sum: INTEGER) is Repeated ance 41 Repeated ance 42 Heirs may include SWISS_ and US_. address age tax_id pass_birthday pay_taxes The two above classes may in turn have a common heir: SWISS_US_. age address tax_id pass_birthday pay_taxes US_ SWISS_ US_ SWISS_ SWISS_US_ 7

8 Repeated ance issues 43 The ance clause 44 What happens with s ed twice from the common ancestor, such as address, age, tax_id, pass_birthday? SWISS_ 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, US_ 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, Sharing and replication 45 The need for select 46 Features such as age and birthday, not d along any of the ance paths, will be shared. Features such as tax_id, ed under different names, will be replicated. ssume there is a redefinition somewhere along the way: address US_ address tax_id pass_birthday pay_taxes SWISS_ address++ US_ SWISS_ address++ address us_address tax_id us_tax_id pay_taxes pay_us_taxes SWISS_US_ address swiss_address tax_id swiss_tax_id pay_taxes pay_swiss_taxes address us_address SWISS_US_ address swiss_address The need for select 47 The need for select 48 potential ambiguity arises because of polymorphism and dynamic binding: potential ambiguity arises because of polymorphism and dynamic binding: t: s: SWISS_ u: US_ su: SWISS_US_ if then t := s else t := su print (t.address) t: su: SWISS_US_ print (t.address) 8

9 Removing the ambiguity 49 When is a name clash acceptable? 50 class SWISS_US_ SWISS_ 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 (etween n s of a class, all with the same name, immediate or ed.) They must all have compatible signatures. If more than one is effective, they must all come from a common ancestor under repeated ance. US_ address as us_address, tax_id as us_tax_id, nother application of renaming 51 The marriage of convenience 52 Provide locally better adapted terminology. class RRYE_STK [G] STK [G] Example: child (TREE); subwinw (WINOW). RRY [G] class LINKE_STK [G] STK [G] LINKE_LIST [G] This is controversial! Others prefer to use the client relation Using ance properly 53 Not the best use in the world 54 Two relations: client, ance lient expresses that instances of must possess information about instances of. Inheritance expresses that every instance of may be viewed as an instance of. From a widely used software engineering textbook: Multiple ance allows several objects to act as base objects and is supported in object-oriented languages such as Eiffel (Meyer, 1988). The characteristics of several different object classes can be combined to make up a new object. For example, say we have an object class R which encapsulates information about cars and an object class PERSON which encapsulates information about people. We could use both of these to define a new object class R-OWNER which combines the attributes of R and PERSON. daptation through ance ts to lead to extra functionality being ed, which can make components inefficient and bulky. 9

10 Inheritance? 55 Inheritance? or client? 56 PERSON R PERSON R R_OWNER R_OWNER The car-owner 57 lient or ance? 58 Except for polymorphic uses, ance is never required: Rather than having from you can always have include an attribute of type (or expanded ) except if an en tity of type may have to represent values of type. He has a head like an ustin Mini with the ors open. (From: The ictionary of ussie Slang, Five-Mile Press, Melbourne, ustralia.) () () To be is also to have! 59 Would you rather buy or? 60 (1) Every software engineer is an engineer. (2) Every software engineer has a part of himself which is an engineer. ut: TO HVE IS NOT LWYS TO E! case in which having is not being (i.e. client is OK but not ance): Every object of type has a component of type, UT that component may need to be replaced during the object s lifetime. Use the client relation instead: class WINOW GENERL_WINOW WINOW_IMPLEMENTTION 10

11 Handles (the bridge pattern) 61 More ance advice 62 class WINOW GENERL_WINOW handle: TOOLKIT set_handle (t: TOOLKIT) is handle := t display is handle.display (urrent) WINOW handle.display (urrent) display+ GTK display* TOOLKIT MS_ WINOWS display+ void taxomania : n t overclassify. Introduce a new class only if it corresponds to a meaningful abstraction, with its own s, usually queries and commands. When in ubt, wait until you are sure that a new class is needed. dding a class is a significant design decision. 63 End of lecture 20 11