Examples of multiple inheritance. Lecture 16: Multiple inheritance & project presentation. Composite figures. Combining abstractions

Transcription

1 hair of Software Engineering Examples of multiple ance Einführung in die Programmierung Introduction to Programming Prof. r. ertrand Meyer October 2006 February 2007 ombining separate abstractions: Restaurant, train car alculator, watch Plane, asset Home, vehicle Lecture 16: Multiple ance & project presentation Intro. to Programming, lecture 16: Multiple ance & project presentation 4 hair of Software Engineering omposite figures Einführung in die Programmierung Introduction to Programming Prof. r. ertrand Meyer October 2006 February 2007 Intro. to Programming, lecture 16: Multiple ance & project presentation 5 ombining abstractions Multiple ance: omposite figures Given the classes TRIN_R, RESTURNT how would you implement a INER? Simple figures composite figure Intro. to Programming, lecture 16: Multiple ance & project presentation 3 Intro. to Programming, lecture 16: Multiple ance & project presentation 6 1

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

3 deferred class OMPRLE [G] feature infix "<" (other: OMPRLE [G]): OOLEN is deferred infix "<=" (other: OMPRLE [G]): OOLEN is do Result := urrent < other or equal (urrent, other) Resolving name clashes as fog as zoo infix ">=" (other: OMPRLE [G]) is infix ">" (other: OMPRLE [G]) is Intro. to Programming, lecture 16: Multiple ance & project presentation 13 Intro. to Programming, lecture 16: Multiple ance & project presentation 16 Lessons from this example Results of renaming We need the full spectrum from fully abstract (fully deferred) to fully implemented classes Multiple ance is there to help us combine abstractions a1: b1: c1: c1.fog c1.zoo a1. b1. as fog as zoo Invalid: a1.fog, a1.zoo, b1.zoo, b1.fog, c1. Intro. to Programming, lecture 16: Multiple ance & project presentation 14 Intro. to Programming, lecture 16: Multiple ance & project presentation 17 Multiple ance: Name clashes Feature merging f* f* f+ Intro. to Programming, lecture 16: Multiple ance & project presentation 15 Intro. to Programming, lecture 16: Multiple ance & project presentation 18 3

4 cceptable name clashes Feature merging: effective features If ed features 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 features into one If there is an effective feature, it imposes its implementation Intro. to Programming, lecture 16: Multiple ance & project presentation 19 Intro. to Programming, lecture 16: Multiple ance & project presentation 22 Feature merging: with different names Undefining a feature g* f* h+ g f h f deferred class T S undefine v feature Intro. to Programming, lecture 16: Multiple ance & project presentation 20 Intro. to Programming, lecture 16: Multiple ance & project presentation 23 Feature merging: with different names Feature merging: effective features class g as f feature h as f class g+ f+ h+ g as f undefine f g f h f f- f- h as f undefine f feature Intro. to Programming, lecture 16: Multiple ance & project presentation 21 Intro. to Programming, lecture 16: Multiple ance & project presentation 24 4

5 Feature merging: effective features Multiple is also repeated ance g+ f+ h+ typical case: NY copy is_equal g f h f f- f- copy++ is_equal++ a1: b1: c1: d1: a1.g b1.f c1.h d1.f?? Intro. to Programming, lecture 16: Multiple ance & project presentation 25 Intro. to Programming, lecture 16: Multiple ance & project presentation 28 special case of multiple ance Repeated ance llow a class to have two or more parents. Examples that come to mind: SSISTNT s from TEHER and STUENT. This is in fact a case of repeated ance?? TEHER UNIVERSITY_ MEMER SSISTNT???? id STUENT?? ssume class with attributes age: INTEGER address: STRING bank_account: OUNT tax_id: INTEGER and routines such as pass_birthday is do age := age + 1 pay_taxes is deposit_to_account (sum: INTEGER) is address age tax_id pass_birthday pay_taxes Intro. to Programming, lecture 16: Multiple ance & project presentation 26 Intro. to Programming, lecture 16: Multiple ance & project presentation 29 Indirect and direct repeated ance Repeated ance Heirs may include SWISS_ and US_. address age tax_id pass_birthday pay_taxes US_ SWISS_ Intro. to Programming, lecture 16: Multiple ance & project presentation 27 Intro. to Programming, lecture 16: Multiple ance & project presentation 30 5

6 Repeated ance The ance clause 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_ 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, Intro. to Programming, lecture 16: Multiple ance & project presentation 31 Intro. to Programming, lecture 16: Multiple ance & project presentation 34 Repeated ance issues The need for select What happens with features ed twice from the common ancestor, such as address, age, tax_id, pass_birthday? ssume there is a redefinition somewhere along the way: address address++ US_ SWISS_ address++ address us_address SWISS_US_ address swiss_address Intro. to Programming, lecture 16: Multiple ance & project presentation 32 Intro. to Programming, lecture 16: Multiple ance & project presentation 35 Sharing and replication The need for select 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. US_ address us_address tax_id us_tax_id pay_taxes pay_us_taxes SWISS_US_ address tax_id pass_birthday pay_taxes SWISS_ address swiss_address tax_id swiss_tax_id pay_taxes pay_swiss_taxes potential ambiguity arises because of polymorphism and dynamic binding: t: su: SWISS_US_ t := su print (t.address) Intro. to Programming, lecture 16: Multiple ance & project presentation 33 Intro. to Programming, lecture 16: Multiple ance & project presentation 36 6

7 Removing the ambiguity 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 Project Presentation US_ address as us_address, tax_id as us_tax_id, Intro. to Programming, lecture 16: Multiple ance & project presentation 37 Intro. to Programming, lecture 16: Multiple ance & project presentation 40 When is a name clash acceptable? Organization (etween n features 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 feature under repeated ance. You can either work alone or team up with another student Team of 2 people from the same exercise group Team members should have similar programming experience Intro. to Programming, lecture 16: Multiple ance & project presentation 38 Intro. to Programming, lecture 16: Multiple ance & project presentation 41 nother application of renaming ontent Provide locally better adapted terminology. Example: child (TREE); subwindow (WINOW). Extension to Traffic You choose what this extension is Examples: Route planner Location information onstruction site marking voiding tram collisions Traffic map editor Intro. to Programming, lecture 16: Multiple ance & project presentation 39 Intro. to Programming, lecture 16: Multiple ance & project presentation 42 7

8 Tasks Implementation and documentation 1. Initial description of the idea 2. Project description, analysis, and design 3. Implementation and documentation Implement and test your application Submit: Your code Only.e files and project ecf file Only relative paths in the ecf file ocumentation: developer guide an reuse parts of the design document eadline: 22 January 2007 Intro. to Programming, lecture 16: Multiple ance & project presentation 43 Intro. to Programming, lecture 16: Multiple ance & project presentation 46 Initial description of the idea Presentations of the project few sentences about what you want to do in the project to your assistant In the exercise sessions: 23 January or (for Knuth group) 25 January eadline: 21 ecember 2006 In the lecture: In the last lecture of the semester (30 January 2007) Intro. to Programming, lecture 16: Multiple ance & project presentation 44 Intro. to Programming, lecture 16: Multiple ance & project presentation 47 Project description, analysis and design Submission procedure Submit: Project description detailed description of the requirements clear statement of how the work will be divided between the 2 group members (if applicable) nalysis and design document short report describing the overall architecture of your system (including a ON class diagram) Everything goes on the wiki: Initial idea as inline text on the page of your project Project description, design document, and developer guide as uploaded PF files Source code as uploaded.zip file eadline: 8 January 2007 Intro. to Programming, lecture 16: Multiple ance & project presentation 45 Intro. to Programming, lecture 16: Multiple ance & project presentation 48 8

9 ssessment criteria esign Extibility Ease of use Functionality oes the implementation satisfy the specification Quality of contracts Preconditions Postconditions lass invariants Loop invariants and variants Intro. to Programming, lecture 16: Multiple ance & project presentation 49 ssessment criteria (continued) ocumentation Project description esign document eveloper guide Quality of code Style guidelines Quality of code Effort devoted to the project Intro. to Programming, lecture 16: Multiple ance & project presentation 50 End of lecture 16 Intro. to Programming, lecture 16: Multiple ance & project presentation 51 9