1. Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session 12 28. October 2008

2. Chair of Software Engineering News  Mock exam next week  No exercise session on Monday  Two hours on Tuesday (13:15 – 15:00) 2

3. Chair of Software Engineering Today’s learning goals  Abstraction  Feature kinds  Exporting features 3

4. Chair of Software Engineering Abstraction  To abstract is to capture the essence behind the details and the specifics  The client is interested in: 4  a set of services that a software module provides, not its internal representation  what a service does, not how it does it class feature  Object-oriented programming is all about finding right abstractions

5. Chair of Software Engineering Discussing abstractions  What abstractions were used in the currency converter from assignment 5? 5  Why it is better to have classes for CURRENCY and MONEY than to store their values in STRING and REAL variables respectively?  What other features could these classes have? Hands-On

6. Chair of Software Engineering Inventing more abstractions  Suppose Credit Suisse liked your currency converter and wants you to extend it to a bank information system  They say: “We should be able to create accounts for our customers in francs, euro and dollars. Clients can perform money transfers between difference accounts at the internal exchange rate”  What abstractions will you add to your application? 6 Hands-On ACCOUNT CUSTOMER TRANSFER BANK ? ? ? ?

7. Chair of Software Engineering Features: the full story 7 Command Query Feature Function No result Feature Memory Computation Client view (specification) ‏ Internal view (implementation) ‏ Returns result Attribute Procedure Memory Computation Routine No result Returns result

8. Chair of Software Engineering Two kinds of routines  Procedure  from the client’s viewpoint is a command  call is an instruction  Function  from the client’s viewpoint is a query  call is an expression 8

9. Chair of Software Engineering Two ways to implement balance 9 (BANK_ACCOUNT) deposits withdrawals 800 (BANK_ACCOUNT) deposits withdrawals balance 1000300 500 1000300 500 invariant: balance = total (deposits) – total (withdrawals) Which one will you choose and why?

10. Chair of Software Engineering Uniform access principle  The client is interested in what a service does, not how it does it  It doesn’t matter for the client, whether you store or compute, he just wants to obtain the balance  Features should be accessible to clients the same way, no matter whether they are implemented by storage or computation 10 my_account.balance

11. Chair of Software Engineering Naming conventions  Names for classes: PASSENGER, STUDENT, NUMERIC, STORABLE  Names for queries: balance, name, first_element, list_of_students  for boolean queries: full, after, is_empty, is_best_choice  Names for commands: run, do_nothing, pimp_my_exersice_session  Composed of English words using underscore  Full English words, but short 11

12. Chair of Software Engineering How do you like these names? class SOLVE_QUADRATIC_EQUATION feature solve (a, b, c: REAL) do... end get_dscrm (a, b, c): REAL do... end how_many_solutions_there_are: INTEGER first_solution, second_solution: REAL end 12 Hands-On

13. Chair of Software Engineering I like these more! 13 class QUADRATIC_EQUATION_SOLVER feature solve (a, b, c: REAL) do... end discriminant (a, b, c): REAL do... end solution_count: INTEGER first_solution, second_solution: REAL end

14. Chair of Software Engineering Exporting features 14  a1. f, a1. g: valid in any client  a1. h: invalid everywhere (including in A’s own text!) ‏  a1. j: valid only in B, C and their descendants (not valid in A!) ‏  a1. m: valid in B, C and their descendants, as well as in A and its descendants Status of calls in a client with a1: A: class A feature f... g... feature {NONE} h, i... feature {B, C} j, k, l... feature {A, B, C} m, n… end

15. Chair of Software Engineering Compilation error? class PERSON feature name: STRING feature {BANK} account: BANK_ACCOUNT feature {NONE} loved_one: PERSON think do print („Thinking of “ + loved_one.name) end lend_100_franks do loved_one.account.transfer (account, 100) end 15 Hands-On OK: unqualified callOK: exported to all OK: unqualified call Error: not exported to PERSON

16. Chair of Software Engineering Adding export status 16 class QUADRATIC_EQUATION feature {?} solve (a, b, c: REAL): do... end feature {?} discriminant (a, b, c): REAL do... end feature {?} solution_count: INTEGER feature {?} first_solution, second_solution: REAL end {NONE} Hands-On

17. Chair of Software Engineering Creation procedures export  For a creation procedure there are two export statuses:  for regular feature callsx.make feature {A, B} make  for creation instructionscreate x.make create {C} make 17

18. Chair of Software Engineering Creation procedures export class ACROBAT_WITH_BUDDY create {?} set_buddy... feature {?} set_buddy do... end end 18 Hands-On class NUCLEAR_REACTOR create {?} initialize_to_default... feature {?} initialize_to_deafult do... end end {NONE} {NUCLEAR_POWER_PLANT}

19. Chair of Software Engineering Exporting attributes  Exporting an attribute only means giving read access x.f := 5  Attributes of other objects can be changed only through commands  protecting the invariant  no need for getter functions! 19

20. Chair of Software Engineering Exporting attributes class TEMPERATURE feature celsius_value, farenheit_value: REAL set_celsius (a_value: REAL) require above_absolute_zero: a_value >= -273.15 do celsius_value := a_value farenheit_value := 9/5 * celsius_value + 32 end invariant above_absolute_zero: celsius_value >= -273.15 correspond: farenheit_value = 9/5 * celsius_value + 32 end 20

21. Chair of Software Engineering Assigners  If you like the syntax x.f := 5 you can declare an assigner for f 21  In class TEMPERATURE celsius_value: REAL assign set_celsuis  In this case t.celsius_value := 36.6 is a shortcut for t.set_celsius (36.6) ... and it won’t break the invariant!