1. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 0 COSC3311 – Software Design Objects, Classes and ADTs Reference vs. Expanded Types

2. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 1 Objects vs. Classes An object is a run-time instance of some class An class is an abstract data type (ADT) with a possible partial implementation

3. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 2 Feature categories by role Command Query Feature Procedure Attribute Function No result Returns result Computation Memory

4. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 3 Feature categories by implementation Procedure Attribute Function Routine Returns result No result Feature Memory Computation

5. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 4 Feature categories Command Query Feature Procedure Attribute Function No result Returns result Computation Memory Routine Returns result No result Feature Memory Computation

6. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 5 Terminology  A class is an implementation of an abstract data type. oInstances of the class may be created at run-time; they are objects. oEvery object is an instance of a class. (In a pure O-O language such as Eiffel and Smalltalk this is true even of basic objects such as integers etc. Not true in C++ or Java where such values have special status.) oA class is characterized by features. Features comprise attributes (representing data fields of instances of the class) and routines (operations on instances). oRoutines are subdivided into procedures (effect on the instance, no result) and functions (result, normally no effect). oEvery operation (routine or attribute call) is relative to a distinguished object, the current instance of the class.

7. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 6 Alternative terminology  Attributes are also called instance variables or data member.  Routines are also called methods, subprograms, or subroutines.  Feature call — applying a certain feature of a class to an instance of that class — is also called passing a message to that object.  The notion of feature is particularly important as it provides a single term to cover both attributes and routines. It is often desirable not to specify whether a feature is an attribute or a routine — as expressed by the Uniform Access principle (see next).

8. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 7 Avoid “objectspeak”  The run-time structures, some of them corresponding to “objects” of the modeled system, are objects.  The software modules, each built around a type of objects, are classes.  A system does not contain any “objects” (although its execution will create objects).

9. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 8 CONTAINER * BOX * COLLECTION * TRAVERSABLE * FINITE * INFINITE * * UNBOUNDED * COUNTABLE * RESIZABLE * BAG * SET * HIERARCHICAL * LINEAR * TABLE * ACTIVE * INTEGER_ INTERVAL * BILINEAR * INDEXABLE * CURSOR_ STRUCTURE * DISPENSER * SEQUENCE * STRINGHASH_TABLESTACK * QUEUE * … … Why the top class is not Object BOUNDED ARRAY ANY

10. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 9 Abstract data type POINT x: POINT  REAL y: POINT  REAL : POINT  REAL : POINT  REAL  Class POINT: Choose a representation (polar, cartesian)  In polar representation,  and  are attributes, x and y are routines. y x  

11. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 10 Abstract data type POINT x: POINT  REAL y: POINT  REAL : POINT  REAL : POINT  REAL  Axiom: y x  

12. Department of Computer Science, York University What is OO programming? Object Oriented Software Construction 30/10/2015 10:54 PM 11 OO = ADTs + inheritance

13. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 12 A simple class class POINT feature x, y: REAL -- Point cartesian coordinates ro: REAL -- Distance to origin (0, 0) do Result := sqrt (x^2 + y^2) end theta: REAL -- Angle to horizontal axis do … end

14. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 13 Uniform access through feature call  To access a property of a point p1, the notation is the same regardless of the representation, e.g. p1.x which is applicable both in cartesian representation (x is an attribute) and in polar representation (x is a function without arguments).  In the first case the feature call is a simple field access; in the second it causes a computation to be performed.  There is no difference for clients (except possibly in terms of performance).

15. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 14 Class POINT (cont’d) distance (p: POINT): REAL -- Distance to p do Result := sqrt ((x – p.x)^2 + (y – p.y)^2) end move (a, b: REAL) -- Move by a horizontally and by b vertically. do x := x + a y := y + b end scale (factor: REAL) -- Scale by factor. do x := factor * x y := factor * y end

16. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 15 Use of the class in a client (1/5) class GRAPHICS feature p, q: POINT -- Graphic points … some_routine -- Use p and q. local u, v: REAL do -- Creation instructions create p create q end 0.0 p (POINT) 0.0 q (POINT)

17. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 16 Use of the class in a client (2/5) class GRAPHICS feature p, q: POINT -- Graphic points … some_routine -- Use p and q. local u, v: REAL do -- Creation instructions create p create q p.move (4.0, -2.0) -- Compare with Pascal, C, Ada: -- Move (p, 4.0, -2.0) end 4.0 -2.0 p (POINT) 0.0 q (POINT)

18. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 17 Use of the class in a client (3/5) class GRAPHICS feature p, q: POINT -- Graphic points … some_routine -- Use p and q. local u, v: REAL do -- Creation instructions create p create q p.move (4.0, -2.0) -- Compare with Pascal, C, Ada: -- Move (p, 4.0, -2.0) p.scale (0.5) end 2.0 p (POINT) 0.0 q (POINT)

19. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 18 Use of the class in a client (4/5) class GRAPHICS feature p, q: POINT -- Graphic points … some_routine -- Use p and q. local u, v: REAL do -- Creation instructions create p create q p.move (4.0, -2.0) -- Compare with Pascal, C, Ada: -- Move (p, 4.0, -2.0) p.scale (0.5) u := p.distance (q) v := p.x p := q end 2.0 p (POINT) 0.0 q (POINT)

20. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 19 Use of the class in a client (5/5) class GRAPHICS feature p, q: POINT -- Graphic points … some_routine -- Use p and q. local u, v: REAL do -- Creation instructions create p create q p.move (4.0, -2.0) -- Compare with Pascal, C, Ada: -- Move (p, 4.0, -2.0) p.scale (0.5) u := p.distance (q) v := p.x p := q p.scale (-3.0) end 2.0 p (POINT) 0.0 q (POINT)

21. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 20 The module-type merge  A class is both: oA module oA type  Much of the conceptual power of the method comes from the fusion of these two notions.  From the module viewpoint: oSet of available services (“features”).  From the type viewpoint: oDescription of set of possible run-time objects (its instances).  Connection: The services of the class, viewed as a module, are the operations applicable to the instances of the class, viewed as a type.

22. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 21 Applying abstraction principles  Privileges of a client C of a class A on query balance: oRead access if attribute is exported.  a.balance is a legal query in class C.  a.balance := 800 is an illegal assignment  read privleges (but not write) CA a: A

23. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 22 Creating an object  With the class POINT as given: my_point: POINT... create my_point  Effect of such a creation instruction: oAllocate new object of the type declared for my_point. oInitialize its fields to default values (0 for numbers, false for booleans, null for characters, void for references). oAttach it to the instruction’s target, here my_point.

24. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 23 Specific creation procedures class POINT create make_cartesian, make_polar feature -- Initialization make_cartesian (a, b: REAL) -- Initialize to abscissa a, ordinate b. do x := a y := b end make_polar(r, t: REAL)... feature... The rest as before...

25. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 24 If there is a creation clause  Creation instructions must be “creation calls”, such as create my_point.make_polar (1, Pi / 2)

26. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 25 If there is no creation clause  An absent creation clause, as in class POINT -- No creation clause feature … The rest as before … end is understood as one that would only list default_create, as if it had been written class POINT create default_create feature … The rest as before … end  Procedure default_create is defined in ANY as doing nothing; any class can redefine it to provide proper default initializations.

27. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 26 Associated convention  The notation create x is understood (if permitted) as an abbreviation for create x.default_create

28. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 27 To allow both forms  To make both forms valid: create my_point.make_cartesian (0, 1) as well as create my_point.make_polar (1, Pi / 2) it suffices to make default_create (redefined or not) one of the creation procedures: class POINT create make_cartesian, make_polar, default_create feature... The rest as before...

29. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 28 To prohibit instantiating a class class NOT_CREATABLE create -- Nothing here! feature... The rest as before... end

30. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 29 Forms of assignment and copy  Reference assignment (a and b of reference types): b := a  Object duplication (shallow): c := a.twin  Object duplication (deep): d := a.deep_twin  Also: shallow field-by-field copy (no new object is created): e.copy (a)

31. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 30 Shallow and deep cloning  Initial situation:  Result of: b := a c := a.twin d := a.deep_twin “Almaviva”name landlord loved_one a O1 “Figaro” O2 “Susanna” O3 b “Almaviva” O4 c “Almaviva”name landlord loved_one O5 “Figaro” O6 “Susanna” O7 d

32. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 31 Equality – Eiffel vs. Java Eiffel  Expanded vs. Reference types (You choose)  Reference equality: x = y  Object equality: x ~ y x.is_equal(y)  Deep equality: deep_equal(x, y)  Change the default by redefining is_equal  STRING redefines is_equal to one level deeper than shallow is_equal Java  Primitives vs. Reference types (No choice)  Reference equality: x == y  Object equality: x.equals(y) (assuming x /= Void)  No built-in deep equality  Change the default by over- riding equals  java.lang.String overrides the java.lang.Object equals() (same as ==)

33. Department of Computer Science, York University Reference vs. Expanded  Every entity must be declared to be of a certain type (based on a class)  Every type is either a reference type or an expanded type ohow to treat attachments in assignments, argument passing & comparisons  In reference types ox := y: x attaches to same object as y ox = y: compares references  In expanded types ox := y: copy contents of y into x ox = y: compares value (x ~ y) Object Oriented Software Construction 30/10/2015 10:54 PM 32

34. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 33 A simple book – basic types A typical instance b of a BOOK is class BOOK feature title: STRING in_print: BOOLEAN pages: INTEGER end

35. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 34 Basic types insufficient class BOOK feature title: STRING in_print: BOOLEAN pages: INTEGER author: expanded WRITER end

36. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 35 author: WRITER  It wastes memory space – the author is the same “Stendhall” in either case.  Does not express sharing. The author field refers to the same instance of WRITER. If you update the WRITER object (e.g. to record year_of_death), you will have to change each sub-object.

37. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 36 Reference types

38. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 37 Reference types [OOSC2, p224]  A reference is a run-time value that is either Void or attached.  If attached, a reference identifies a single object (and is said to be attached to that object).

39. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 38 The dynamic model for references  States of a reference:  Operations on references: create p p := q p := Void if p = Void then... VOIDATTACHED create p p := q (where q is attached) p := Void p := q (where q is void) p ATTACHED p VOID

40. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 39 Modelling Fidelity  A void reference can denote an unknown author. “Candide” was published anonymously.

41. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 40 Aliasing  Dynamic aliasing is not just a consequence of a programmer’s dirty tricks — it is a consequence of the human ability to name things, and to give more than one name to the same thing.  However, aliasing is shocking – changing author_relativity has the side effect of changing nobel_winner_1921 – this causes many programmer errors!

42. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 41 Aliasing problems  Blurb from the International Workshop on Aliasing, Confinement and Ownership in Object-Oriented programming (IWACO) July 22, 2003:  “The power of objects lies in the flexibility of their interconnection structure. But this flexibility comes at a cost. Because an object can be modified via any alias, object-oriented programs are hard to understand, maintain, and analyse. Aliasing makes objects depend on their environment in unpredictable ways, breaking the encapsulation necessary for reliable software components, making it difficult to reason about and optimize programs, obscuring the flow of information between objects, and introducing security problems.”

43. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 42 Why aliasing?  Modelling Fidelity (see earlier slide)  We need references (particularly sharing) just to do certain kinds of data structures. oConsider a LINKED_CIRCULAR_LISTS — with a node first linked to one of the nodes (say n) in the circle. oThen first and node (n-1) both share a reference to n.

44. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 43 Expanded vs. References

45. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 44 Reference POINT vs. Expanded POINT  Reference: sharing  Aliasing  Expanded: no sharing  Sub-object a

46. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 45 BON diagram class WORKSTATION feature k: expanded KEYBOARD c: expanded CPU m: expanded MONITOR n: NETWORK end

47. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 46 BON: Associations vs. Aggregations  Reference: association  Expanded: aggregation

48. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 47 Java Strings are Immutable public class EqualityTest2 { public static void main(String[] args) { char c1, c2; String s1,s2,s3; c1 = 'c'; c2 = 'c'; s1 = "hello"; s2 = "hello"; //same string literal s3 = s1; String s4 = new String("hello"); check("t1", c1 == c2);//PASS check("t2", new Character(c1).equals(new Character(c2)));//PASS check("t4",s1 == s2);//PASS check("t5",s1.equals(s2));//PASS check("t7",s1 == s3);//PASS check("t8",s4 == "hello");//FAIL //above are different objects check("t9",s4.equals("hello")); }//PASS public static void check(String s, boolean b) { String st = (b)?"passed":"failed"; System.out.println(s+": "+st); }}

49. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 48 Eiffel Strings are Mutable test_string_equality: BOOLEAN local s1, s2, s3: STRING do check s1 = Void end s1 := "hello" s2 := "hello“ check s1 /= s2 end s3 := s1 check s1 = s3 end create s2.make_from_string ("hello") check s1 /= s2 end check s1.is_equal (s2) end check s1 = s3 and s3 /= s2 end Result := true end

50. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 49 CHARACTER is expanded test_character_equality: BOOLEAN local c1,c2, c3: CHARACTER do check c1 = '%U' and c2 = '%U' end c1 := 'c' c2 := 'c' c3 := c1 Result := c1 = c2 and equal(c1,c2) and c1 = c3 check Result end end

51. Department of Computer Science, York University Object Oriented Software Construction 30/10/2015 10:54 PM 50 Reference types implies Aliasing  Bad io.read_line -- “Jesse” s1 := io.last_string io.read_line -- “Helen” s2 := io.last_string check s1 = s2 and s1 = “Helen” end  Good io.read_line s1 := io.last_string.twin io.read_line s2 := io.last_string.twin