Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.

Slides:



Advertisements
Similar presentations
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
Advertisements

Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 7: References and Assignment.
Chapter 7: User-Defined Functions II Instructor: Mohammad Mojaddam.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session November 2008.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 6.
Chair of Software Engineering Constants, once routines, and helper functions these slides contain advanced material and are optional.
Chapter 5: Elementary Data Types Properties of types and objects –Data objects, variables and constants –Data types –Declarations –Type checking –Assignment.
Defining classes and methods Recitation – 09/(25,26)/2008 CS 180 Department of Computer Science, Purdue University.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 2: Dealing with Objects I.
1 Programming for Engineers in Python Autumn Lecture 5: Object Oriented Programming.
1 Chapter 4 Language Fundamentals. 2 Identifiers Program parts such as packages, classes, and class members have names, which are formally known as identifiers.
1 Advanced Material The following slides contain advanced material and are optional.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 3.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 4: The Interface of a Class.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 4.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 4: The Interface of a Class.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 9: Abstraction.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 4.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering OOSC - Lecture 21 1 Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering Avoid a void Bertrand Meyer ©Bertrand Meyer, 2008.
Chair of Software Engineering 1 Introduction to Programming Tuples and Agents Exercise Session 1 and 2 December 2008.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 7: References and Assignment.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 4.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
Data Abstraction and Object- Oriented Programming CS351 – Programming Paradigms.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 3.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 10.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 7.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 10.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 9: Abstraction.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 3.
Chair of Software Engineering ATOT - Lecture 22, 18 June Advanced Topics in Object Technology Bertrand Meyer.
Ranga Rodrigo. Class is central to object oriented programming.
CSM-Java Programming-I Spring,2005 Introduction to Objects and Classes Lesson - 1.
Writing Classes (Chapter 4)
EE4E. C++ Programming Lecture 1 From C to C++. Contents Introduction Introduction Variables Variables Pointers and references Pointers and references.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Programming in Java Unit 2. Class and variable declaration A class is best thought of as a template from which objects are created. You can create many.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Copyright © 2002, Systems and Computer Engineering, Carleton University a-JavaReview.ppt * Object-Oriented Software Development Unit.
More About Classes Ranga Rodrigo. Information hiding. Copying objects.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 9.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
Chapter 8 Objects and Classes Object Oriented programming Instructor: Dr. Essam H. Houssein.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 4.
OOP in C++ CS 124. Program Structure C++ Program: collection of files Source (.cpp) files be compiled separately to be linked into an executable Files.
UMass Lowell Computer Science Java and Distributed Computing Prof. Karen Daniels Fall, 2000 Lecture 9 Java Fundamentals Objects/ClassesMethods Mon.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 3.
Application development with Java Lecture 21. Inheritance Subclasses Overriding Object class.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
C++ for Java Programmers Chapter 2. Fundamental Daty Types Timothy Budd.
Programmeren 1 6 september 2010 HOORCOLLEGE 2: INTERACTIE EN CONDITIES PROGRAMMEREN 1 6 SEPTEMBER 2009 Software Systems - Programming - Week.
Programming Fundamentals. Topics to be covered Today Recursion Inline Functions Scope and Storage Class A simple class Constructor Destructor.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 4.
DBC NOTES. Design By Contract l A contract carries mutual obligations and benefits. l The client should only call a routine when the routine’s pre-condition.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
Chapter 4: Variables, Constants, and Arithmetic Operators Introduction to Programming with C++ Fourth Edition.
Copyright © 2012 Pearson Education, Inc. Chapter 4 Writing Classes : Review Java Software Solutions Foundations of Program Design Seventh Edition John.
Friend Class Friend Class A friend class can access private and protected members of other class in which it is declared as friend. It is sometimes useful.
Einführung in die Programmierung Introduction to Programming Prof. Dr
Einführung in die Programmierung Introduction to Programming Prof. Dr
Recap Week 2 and 3.
Einführung in die Programmierung Introduction to Programming Prof. Dr
Presentation transcript:

Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5

2 Today  Reference types vs. expanded types  Assignment  Basic types  Local variables  Qualified and unqualified calls  Entities and variables: summary

3 What are reference and expanded types? Reference types: s contains the address (reference, or location), of the object. Example: s : STATION Expanded types: p points directly to the object. Example: p : POINT s (STATION ) p AB3409E1 A00897BC (POINT ) AB3409E1

4 Declaration of reference and expanded types Objects of reference types: they don’t exist when we declare them (they are initially Void). s : STATION We need to explicitly create them with a create instruction. create s Objects of expanded types: they exist by just declaring them (they are never Void) p : POINT Feature default_create from ANY is implicitly invoked on them

5 Can expanded types contain reference types? Expanded types can contain reference types, and vice versa. c (SOME_CLASS ) (COUPLE ) (HUMAN) 10 20

6 Reference equality a = b ? (VECTOR ) a b (VECTOR ) (VECTOR ) b a True False

7 Expanded entities equality Entities of expanded types are compared by value! a = b ? True a (SOME_CLASS ) (POINT ) b (POINT )

8 Expanded entities equality (SOME_CLASS ) (HUMAN) 32 John (HUMAN) b a 30 Jane (HUMAN) 32 John (HUMAN) 30 Jane a = b ? False Hands-On (COUPLE ) 10 (COUPLE ) 10

9 Expanded entities equality Hands-On (HUMAN) 32 John (HUMAN) 30 Jane a = b ? True (SOME_CLASS ) b a (COUPLE ) 10 (COUPLE ) 10

Why expanded types?  Representing basic types (INTEGER, REAL,…)  Modeling external world objects realistically, i.e. describing objects that have sub-objects (and no sharing), for example a class WORKSTATION and its CPU.  Possible efficiency gain.  Interface with other languages.

11 Assignment  Assignment is an instruction (What other instructions do you know?)  Syntax: a := b  where a is a variable (e.g., attribute) and b is an expression (e.g. argument, query call);  a is called the target of the assignment and b the source.  Semantics:  after the assignment a equals b (a = b);  the value of b is not changed by the assignment.

12 Reference assignment (VECTOR ) a 0.0 (VECTOR ) b a := b a references the same object as b: a = b

13 Expanded assignment a (POINT ) b (POINT ) a := b The value of b is copied to a, but again: a = b

14 Assignment Explain graphically the effect of an assignment: Hands-On (HUMAN) 32 „John“ (HUMAN) a 30 „Jane“ (HUMAN) 25 „Dan“ (HUMAN) 24 „Lisa“ (COUPLE ) 10 a := b b (COUPLE ) 4 4 Here COUPLE is an expanded class, HUMAN is a reference class

15 Attachment  More general term than assignment  Includes:  Assignment a := b  Passing arguments to a routine f (a: SOME_TYPE) do … end f (b)  Same semantics

16 Dynamic aliasing a, b: VECTOR … create b.make (1.0, 0.0) a := b  now a and b reference the same object (they are two names or aliases of the same object)  any change to the object attached to a will be reflected when accessing it using b  any change to the object attached to b will be reflected when accessing it using a (VECTOR ) a b x y

17 Dynamic aliasing What are the values of a.x, a.y, b.x and b.y after executing instructions 1-4? a, b: VECTOR … create a.make (-1.0, 2.0) 1create b.make (1.0, 0.0) 2a := b 3b.set_x (5.0) 4a.set_y (-10.0) Hands-On (VECTOR ) a b x y

18 How to declare an expanded type To get an expanded type, declare a class with keyword expanded: expanded class COUPLE feature -- Access man, woman: HUMAN years_together: INTEGER end Now all the entities of type COUPLE will automatically become expanded: pitt_and_jolie: COUPLE Expanded Reference ?

19 Basic types Their only privilege is to use manifest constants to construct their instances: b: BOOLEAN x: INTEGER c: CHARACTER s: STRING … b := True x := 5 -- instead of create x.make_five c := ‘c’ s := “I love Eiffel”

20 Basic types  Some basic types (BOOLEAN, INTEGER, NATURAL, REAL, CHARACTER) are expanded… a := b  … and immutable (they do not contain commands to change the state of their instances)… a := a.plus (b)instead ofa.add (b) 5 b 3 a 5 a 5 b a + b Alias for add

21 Strings are a bit different Strings in Eiffel are not expanded… s: STRING … and not immutable s := “I love Eiffel” s.append (“ very much!”) Ilov sarea count e

22 String comparison: = versus is_equal s1: STRING = “Teddy” s2: STRING = “Teddy” … s1 = s2 -- False: reference comparison on different objects s1.is_equal (s2) –True … Now you know what to do if interested in comparing the content of two strings

23 Initialization Default value of any reference type is Void Default values of basic expanded types are:  False for BOOLEAN  0 for numeric types (INTEGER, NATURAL, REAL)  “null” character (its code is 0) for CHARACTER Default value of a non-basic expanded type is an object, whose fields have default values of their types (COUPLE ) 0

24 Initialization What is the default value for the following classes? expanded class POINT feature x, y: REAL end class VECTOR feature x, y: REAL end STRING Hands-On 0.0 (POINT) x y Void

25  Expanded classes are not creatable using a creation feature of your choice expanded class POINT create make feature make do x := 5.0; y := 5.0 end... end  But you can use (and possibly redefine) default_create expanded class POINT inherit ANY redefine default_create feature default_create do x := 5.0; y := 5.0 end Custom initialization for expanded types Incorrect

26 Some variables are only used by a certain routine. Declare them as local: feature f (arg1: A …) require... local x, y : B z : C do … ensure... end Local variables

27 The scope of names Attributes:  declared anywhere inside a feature clause, but outside other features  visible anywhere inside the class  visible outside the class (depending on their visibility) Formal arguments:  declared after the feature name, in parenthesis  only visible inside the feature body and its contracts Local variables:  declared in a local clause inside the feature declaration  only visible inside the feature body

28 Compilation error? (1) class PERSON feature name: STRING set_name (a_name: STRING) do name := a_name end exchange_names (other: PERSON) local s: STRING do s := other.name other.set_name (name) set_name (s) end print_with_semicolon do create s.make_from_string (name) s.append (“;”) print (s) end Hands-On Error: this variable was not declared

29 Compilation error? (2) Hands-On class PERSON feature …-- name and set_name as before exchange_names (other: PERSON) local s: STRING do s := other.name other.set_name (name) set_name (s) end print_with_semicolon local s: STRING do create s.make_from_string (name) s.append (“;”) print (s) end OK: two different local variables in two routines

30 An example of side effects Hands-On class PERSON feature … name: STRING print_with_semicolon local s: STRING do create s.make_from_string (name) s.append (“;”) print (s) end print_with_sticky_semicolon do name.append (“;”) print (name) end Now the semicolon sticks to the attribute. This is called side effect

31 Compilation error? (3) class PERSON feature …-- name and set_name as before s: STRING exchange_names (other: PERSON) do s := other.name other.set_name (name) set_name (s) end s: STRING print_with_semicolon do create s.make_from_string (name) s.append (“;”) print (s) end Hands-On Error: an attribute with the same name was already defined

32 Compilation error? (4) class PERSON feature …-- name and set_name as before exchange_names (other: PERSON) do s := other.name other.set_name (name) set_name (s) end print_with_semicolon do create s.make_from_string (name) s.append (‘;’) print (s) end s: STRING end Hands-On OK: a single attribute used in both routine

33 Local variables vs. attributes  Which one of the two correct versions (2 and 4) do you like more? Why?  Describe the conditions under which it is better to use a local variable instead of an attribute and vice versa Hands-On

34 Result  Inside every function you can use the predefined local variable Result (you needn’t and shouldn’t declare it)  The return value of a function is whatever value the Result variable has at the end of the function execution  At the beginning of routine’s body Result (as well as regular local variables) is initialized with the default value of its type  Every regular local variable is declared with some type; and what is the type of Result? It’s the function return type!

35 Compilation error? (5) class PERSON feature …-- name and set_name as before exchange_names (other: PERSON) do Result := other.name other.set_name (name) set_name (Result) end name_with_semicolon: STRING do create Result.make_from_string (name) Result.append(‘;’) print (Result) end Hands-On Error: Result can not be used in a procedure

36  In object-oriented computation each routine call is performed on a certain object  From inside a routine we can access this object using the predefined entity Current Current (STATION ) x.change_name (y) change_name (n: STRING) do … city.internal_stations.ext end (Current, n) end  What is the type of Current?

37  If the target of a feature call is Current, it is omitted: Current.f (a) f (a) Revisiting qualified vs. unqualified feature calls  Such a call is unqualified  Otherwise, if the target of a call is specified explicitly, the call is qualified x.f (a)

38 Qualified or unqualified? Are the following feature calls, with their feature names underlined, qualified or unqualified? What are the targets of these calls? 1)x.y 2)x 3)f (x.a) 4)x.y.z 5)x (y.f (a.b)) 6)f (x.a).y (b) 7)Current.x Hands-On qualified unqualified qualified unqualified qualified

39 Assignment to attributes  Direct assignment to an attribute is only allowed if an attribute is called in an unqualified way: y := 5 x.y := 5 Current.y := 5  There are two main reasons for this rule: 1.A client may not be aware of the restrictions on the attribute value and interdependencies with other attributes => class invariant violation (Example?) 2.Guess! (Hint: uniform access principle) OK Error ?

40 Entity: the final definition  variable attribute  constant attribute Only a variable can be used in a creation instruction and in the left part of an assignment An entity in program text is a “name” that directly denotes an object. More precisely: it is one of  attribute name  formal argument name  local variable name  Result  Current Read-write entities / variables Read-only entities

41 Find 5 errors class VECTOR feature x, y: REAL copy_from (other: VECTOR) do Current := other end copy_to (other: VECTOR) do create other other.x := x other.y := y end reset do create Current end Hands-On Current is not a variable and can not be assigned to other is a formal argument (not a variable) and thus can not be used in creation other.x is a qualified attribute call (not a variable) and thus can not be assigned to the same reason for other.y Current is not a variable and thus can not be used in creation

42 Clients and suppliers If class C mentions class A in its text (e.g., declares an entity of type A), then  C is a client of A  A is a supplier of C A class can be a supplier (and a client) of itself (you’ll see one in next week) AC C

43 Clients and suppliers Hands-On How many suppliers does class COUPLE have? What are they? class COUPLE feature man, woman: HUMAN years_together: INTEGER print_wedding_invitation local s: STRING p: INVITATION_PRINTER do s := “We are happy to invite you to the wedding of ” + man.name + “ and ” + woman.name + “!” create p p.print (s, 50) end

44 Why expanded types?  Efficiency  No extra memory cost beyond that for the object  Direct access to attributes  Modeling b (TIRE) (CAR) a (TIRE) (CAR) No tire would be shared among cars b (CAR) a (TIRE) A tire could be shared among cars