1. Copyright 2002 by S. Haridi and P. Van Roy1 Object-Oriented Programming Seif Haridi Peter Van Roy

2. Copyright 2002 by S. Haridi and P. Van Roy2 Object-oriented programming We present a rich style in program structure based on a collection of stateful entities (abstract data types) Most popular current representatives are C++, and Java An object-oriented design model Principle programming techniques Relation to other models (higher order programming, component based programming, functional) Case-study in object-oriented language (based on Mozart/Oz)

3. Copyright 2002 by S. Haridi and P. Van Roy3 Component based programming Supports –Encapsulation –Compositionality –Instantiation

4. Copyright 2002 by S. Haridi and P. Van Roy4 Object-oriented programming Supports –Encapsulation –Compositionality –Instantiation Plus –Inheritance

5. Copyright 2002 by S. Haridi and P. Van Roy5 Inheritance Programs can be built in hierarchical structure from data abstractions that depend on other data abstractions (Components) The object style of data abstraction is the default, not the ADT style Object-oriented programming (inheritance) is based on the idea that data abstractions have much in common Example, sequences (stacks, lists, queues) Object oriented programming builds data abstractions incrementally, this is done by inheritance A data abstraction can be defined to ”inherit” from another abstract datatype, have substantially the same functionality of the other abstract datatype Only the difference between a data abstraction and its ancestor has to be specified

6. Copyright 2002 by S. Haridi and P. Van Roy6 What is object-oriented programming? OOP (Object-oriented programming) = encapsulated state + inheritance Object –An entity with unique identity that encapsulate state –state can be accessed in a controlled way from outside –The access is provided by means of methods (procedures that can directly access the internal state) Class –A specification of objects in an incremental way –By inheriting from other classes –And specifying how its objects (instances) differ from the objects of the inherited classes

7. Copyright 2002 by S. Haridi and P. Van Roy7 Instances (objects) Interface (what methods are available) State (attributes) procedures (methods)

8. Copyright 2002 by S. Haridi and P. Van Roy8 Classes as complete spec of a data abstraction We start our case study elements of a class (members) –attributes (multable instance variables) –features (stateless info about objects) –methods

9. Copyright 2002 by S. Haridi and P. Van Roy9 Classes (syntax simple) A class is a statement class  ClassVariable  attr  AttrName1  :  AttrNameN  meth  Pattern1   Statement  end : meth  PatternN   Statement  end end

10. Copyright 2002 by S. Haridi and P. Van Roy10 Classes (syntax simplified) A class is also a value that can be in an expression position class $ attr  AttrName1  :  AttrNamen  meth  Pattern   Statement  end : meth  Pattern   Statement  end end

11. Copyright 2002 by S. Haridi and P. Van Roy11 Classes in Oz The class Counter has the syntactic form class Counter attr val meth browse {Browse @val} end meth inc(Value) val := @val + Value end meth init(Value) val := Value end end

12. Copyright 2002 by S. Haridi and P. Van Roy12 Attributes of Classes The class Counter has the syntactic form class Counter attr val meth browse {Browse @val} end meth inc(Value) val := @val + Value end meth init(Value) val := Value end end val is an attribute a modifiable cell that is access by the atom val

13. Copyright 2002 by S. Haridi and P. Van Roy13 Attributes of classes The class Counter has the syntactic form class Counter attr val meth browse {Browse @val} end meth inc(Value) val := @val + Value end meth init(Value) val := Value end end the attribute val is accessed by the operator @ val

14. Copyright 2002 by S. Haridi and P. Van Roy14 Attributes of classes The class Counter has the syntactic form class Counter attr val meth browse {Browse @val} end meth inc(Value) val := @val + Value end meth init(Value) val := Value end end the attribute val is assigned by the operator := as val :=...

15. Copyright 2002 by S. Haridi and P. Van Roy15 Methods of classes The class Counter has the syntactic form class Counter attr val meth browse {Browse @val} end meth inc(Value) val := @val + Value end meth init(Value) val := Value end end methods are statements method head is a record (tuple) pattern

16. Copyright 2002 by S. Haridi and P. Van Roy16 Classes in Oz The class Counter has the syntactic form class Counter attr val meth browse {Browse @val} end meth inc(Value) val := @val + Value end meth init(Value) val := Value end end

17. Copyright 2002 by S. Haridi and P. Van Roy17 Example The following shows how an object is created from a class using the procedure New/3, whose first argument is the class, the second is the initial method, and the result is the object. New/3 is a generic procedure for creating objects from classes. declare C = {New Counter init(0)} {C browse} {C inc(1)} {C browse}

18. Copyright 2002 by S. Haridi and P. Van Roy18 Example The following shows how an object is created from a class using the procedure New/3, whose first argument is the class, the second is the initial method, and the result is the object. New/3 is a generic procedure for creating objects from classes. declare C = {New Counter init(0)} {C browse} {C inc(1)} {C browse} Object interface is as a procedure with one argument (see procedure dispatch method Chapter 8)

19. Copyright 2002 by S. Haridi and P. Van Roy19 A class X is defined by: –class X... end Attributes are defined using the attribute-declaration part before the method-declaration part: –attr A 1... A N Then follows the method declarations, each has the form: –meth E S end The expression E evaluates to a method head, which is a record whose label is the method name. Summary

20. Copyright 2002 by S. Haridi and P. Van Roy20 An attribute A is accessed using @A. An attribute is assigned a value using A := E A class can be defined as a value: X = class $... end Summary

21. Copyright 2002 by S. Haridi and P. Van Roy21 Attribute Initialization Stateful (may be updated by := ) Initialized at object creation time, all instances have the initial balance = 0 class Account attr balance:0 meth … end … end In general the initial value of an attribute could be any legal value (including classes and objects)

22. Copyright 2002 by S. Haridi and P. Van Roy22 Attribute Initialization Initialization by instance class Account attr balance meth init(X) balance := X end … end C1 = {New Account init(100)} C1 = {New Account init(50)}

23. Copyright 2002 by S. Haridi and P. Van Roy23 Attribute initialization Initialization by brand declare L=linux class RedHat attr ostype:L meth get(X) X = @ostype end end class SuSE attr ostype:L meth get(X) X = @ostype end end class Debian attr ostype:L meth get(X) X = @ostype end end

24. Copyright 2002 by S. Haridi and P. Van Roy24 Example class Queue attr front back count meth init Q in front := Q back := Q count := 0 end meth put(X) Q in @back = X|Q back := Q count := @count + 1 end... end

25. Copyright 2002 by S. Haridi and P. Van Roy25 Example class Queue attr front back count meth init Q in front := Q back := Q count := 0 end meth put(X) Q in @back = X|Q back := Q count := @count + 1 end... end front back Q0 front back a | Q1 put(a)

26. Copyright 2002 by S. Haridi and P. Van Roy26 Example class Queue attr front back count... meth get(?X) Q in X|Q = @front front := Q count := @count - 1 end meth count(X) X = @count end... end front back a | Q1 X front back a | Q1 X

27. Copyright 2002 by S. Haridi and P. Van Roy27 Classes as incremental specs of data abstractions Object-oriented programming allows allows us to define a class by extending existing classes Three things have to be introduced –How to express inheritance, and what does it mean? –How to access particular methods in the new class and in preexisting classes –Visibility – what part of the program can see the attributes and methods of a class The notion of delegation as a substitute for inheritance

28. Copyright 2002 by S. Haridi and P. Van Roy28 Inheritance Inheritance should be seen as a way to specialize a class while retaining the relationship between methods In this way it is a just an extension of a data abstraction The other view is inheritance is just a (lazy) way to construct new abstract data types ! No relationships are preserved general class specialized class

29. Copyright 2002 by S. Haridi and P. Van Roy29 Inheritance class Account attr balance:0 meth transfer(Amount) balance := @balance+Amount end meth getBal(B) B = @balance end A={New Account transfer(100)}

30. Copyright 2002 by S. Haridi and P. Van Roy30 Inheritance II Conservative extension class VerboseAccount from Account meth verboseTransfer(Amount)... end The class VerboseAccount has the methods: transfer, getBal, and verboseTransfer

31. Copyright 2002 by S. Haridi and P. Van Roy31 Inheritance II Non-Conservative extension class AccountWithFee from VerboseAccount attr fee:5 meth transfer(Amount)... end The class AccountWithFee has the mothods: transfer, getBal, and verboseTransfer The method transfer has been redefined (overridden) with another definition

32. Copyright 2002 by S. Haridi and P. Van Roy32 Inheritance II Non-Conservative extension class AccountWithFee from VerboseAccount attr fee:5 meth transfer(Amount)... end Account VerboseAccount AccountWithFee

33. Copyright 2002 by S. Haridi and P. Van Roy33 Static and dynamic binding Dynamic binding Inside an object O we want to invoke a method M This is written as {self M}, and chooses the method visible in the current object (M of D) class C meth M class D a subclass of C meth M O an instance of D

34. Copyright 2002 by S. Haridi and P. Van Roy34 Static and dynamic binding Static binding Inside an object O we want to invoke a method M in a specific (super) class This is written as C, M and chooses the method visible in the super class C (M of C) class C meth M class D a subclass of C meth M O an instance of D

35. Copyright 2002 by S. Haridi and P. Van Roy35 Static method calls Given a class and a method head m(…), a static method-call has the following form: C, m(…) Invokes the method defined in the class argument. A static method call can only be used inside class definitions. The method call takes the current object denoted by self as implicit argument. The method m could be defined in the class C, or inherited from a super class.

36. Copyright 2002 by S. Haridi and P. Van Roy36 Inheritance class Account attr balance:0 meth transfer(Amount) balance := @balance+Amount end meth getBal(B) B = @balance end A={New Account transfer(100)}

37. Copyright 2002 by S. Haridi and P. Van Roy37 Inheritance II Conservative extension class VerboseAccount from Account meth verboseTransfer(Amount) { self transfer(Amount)} {Show @balance} end The class VerboseAccount has the methods: transfer, getBal, and verboseTransfer

38. Copyright 2002 by S. Haridi and P. Van Roy38 Inheritance III Non-Conservative extension class AccountWithFee from VerboseAccount attr fee:5 meth transfer(Amount) VerboseAccount, transfer(Amount - @fee) end The class AccountWithFee has the mothods: transfer, getBal, and verboseTransfer The method transfer has been redefined (overridden) with another definition

39. Copyright 2002 by S. Haridi and P. Van Roy39 Inheritance IV Non-Conservative extension class AccountWithFee from VerboseAccount attr fee:5 meth transfer(Amount) VerboseAccount, transfer(Amount - @fee) end Non-Conservative inheritance is dangerous because it might change the relationship between methods and just invariants the programmer depends on Account invariant: getBalance(B1); transfer(S); getBalance(B2)  B1+S=B2 No longer satisfied!

40. Copyright 2002 by S. Haridi and P. Van Roy40 Inheritance graph Classes may inherit from one or several classes appearing after the keyword from A class B is a superclass of a class A if: –B appears in the from declaration of A, or –B is a superclass of a class appearing in the from declaration of A. The attributes and methods available in a class C (i.e. visible) are defined through a precedence relation on the methods that appear in the class hierarchy, called the overriding relation: –A method in a class C overrides any method, with the same label, in any super class of C.

41. Copyright 2002 by S. Haridi and P. Van Roy41 SuperClass relation C SuperClass relation is directed and acyclic.

42. Copyright 2002 by S. Haridi and P. Van Roy42 SuperClass relation C SuperClass relation is directed and acyclic. After striking out all overridden methods each remaining method should have a unique label and is defined only in one class in the hierarchy.

43. Copyright 2002 by S. Haridi and P. Van Roy43 Inheritance relation C m m m A (valid hierarchy) (invalid hierarchy)

44. Copyright 2002 by S. Haridi and P. Van Roy44 Multiple inheritance example class Account attr balance:0 meth transfer(Amount) balance := @balance+Amount end meth getBal(?B) B = @balance end end class Customer attr name meth init(N) name := N end end class CustomerAccount from Customer Account end A={New CustomerAccount init}

45. Copyright 2002 by S. Haridi and P. Van Roy45 Illegal inheritance class Account attr balance meth init(Amount) balance := Amount end meth transfer(Amount) balance := @balance+Amount end meth getBal(B) B = @balance end end class Customer attr name meth init(N) name := N end end class CustomerAccount from Customer Account end

46. Copyright 2002 by S. Haridi and P. Van Roy46 Legal inheritance class Account attr balance meth init(Amount) balance := Amount end meth transfer(Amount) balance := @balance+Amount end meth getBal(B) B = @balance end end class Customer attr name meth init(N) name := N end end class CustomerAccount from Customer Account meth init(N A) Customer, init(N) Account, init(A) end CustomerAccount has attributes balance and name methods init, transfer and getBalance This overriding is not harmful it does not change relationships in super classes

47. Copyright 2002 by S. Haridi and P. Van Roy47 Controlling visibility Visibility is the control given to the user to limit access to members of a class (attributes and methods) Each member (attribute or method) is defined with a scope (part of program text that the member can be accessed by name) Programming languages use words like public, private, and protected to define visibility Unfortunately, different languages use these keywords to define different scopes –Source of enormous confusion! Be careful!

48. Copyright 2002 by S. Haridi and P. Van Roy48 Public and private scopes In Smalltalk and Oz, a private member is one which is only visible in the object instance –The object instance can see all the private members in its class and its super classes In C++ and Java, a private member is visible among all instances of a given class, but not to subclasses A public member is visible anywhere in the program By default, attributes are private and methods are public

49. Copyright 2002 by S. Haridi and P. Van Roy49 Public and private scopes Other scopes can be programmed by using name values (as we saw for secure ADTs) For example, let us make a method private within a class (like C++ and Java) The method name is a name value –Define a new name A –Use the syntax !A for the method name Short-cut: –Use the syntax A for the method name makes the NewName implicit With names, any kind of privacy can be programmed local A={NewName} in class C meth !A(...)... end... end class C meth A(...)... end... end

50. Copyright 2002 by S. Haridi and P. Van Roy50 Summary of scopes In Java, in order from least to most visible: Private: accessible within a class (among all its objects) Package: accessible within a package Protected: accessible within a package and to subclasses Public: accessible to all In Oz, in order from least to most visible: Private: accessible within one object (not possible in Java!) Programmed (with name value): any accessibility Public: accessible to all

51. Copyright 2002 by S. Haridi and P. Van Roy51 Programming techniques Constructing a hierarchy by following the type Abstract and concrete classes First class messages Parameterized classes Use of multiple inheritance

52. Copyright 2002 by S. Haridi and P. Van Roy52 Constructing a hierarchy by following the type I class ListClass … end class NilClass from ListClass … end class ConsClass from ListClass … end ListClass NilClassConsClass General lists have the following definition  list T  ::= nil [] T |  list  Constructing a hierarchy following this definition guarantees that the substitution principle is followed

53. Copyright 2002 by S. Haridi and P. Van Roy53 Constructing a hierarchy by following the type II class ListClass meth append(_ _) raise undefinedMethod end end end class NilClass from ListClass meth init skip end meth append(T U) U=T end end class ConsClass from ListClass attr head tail meth init(H T) head:=H tail:=T end meth append(T U) U2 in {@tail append(T U2)} U={New ConsClass init(@head U2)} end declare L1 L2 L3 in L1={New ConsClass init(1 {New ConsClass init(2 {New NilClass init})})} L2={New ConsClass init(3 {New NilClass init})} {L1 append(L2 L3)} {L3 display} % Definition not shown

54. Copyright 2002 by S. Haridi and P. Van Roy54 Abstract and concrete classes ListClass NilClassConsClass ListClass is an abstract class, i.e., a class in which some methods are left undefined (such as init and append ) Abstract classes are not intended to be instantiated, but inherited from Inheritance “fills in the blanks” by adding the missing methods The result is a concrete class, i.e., a class that can be instantiated since all its methods are defined NilClass and ConsClass are concrete classes This technique is an example of higher-order programming (namely genericity: passing a procedure value, i.e., a method)

55. Copyright 2002 by S. Haridi and P. Van Roy55 Techniques of higher-order programming Control abstractions class HO meth forAll(LO M) for O in LO do {O M} end end... end This technique allows messages as parameters

56. Copyright 2002 by S. Haridi and P. Van Roy56 Parameterized classes Classes are values like any other value Therefore is it possible to define functions that return new classes as output fun {MakeClassAcountWithFee Fee} class $ % Fee is in context environment from Account meth init(Amount) Account, init(Amount-Fee) end Account={MakeClassAccountWithFee 100} {New Account init(1000)}

57. Copyright 2002 by S. Haridi and P. Van Roy57 Classes as first-class values fun {MakeClassAcountWithFee Fee} class $ % Fee is in closure from Account meth init(Amount) Account,init(Amount-Fee) end Account={MakeClassAccountWithFee 100} {New Account init(1000)}

58. Copyright 2002 by S. Haridi and P. Van Roy58 Forwarding and delegation Inheritance, as we saw it, is one way to define new functionality from existing functionality Inheritance can be tricky to use well, because it implies a tight binding between the original and new classes Two looser approaches, which are sometimes better, are forwarding and delegation: –“If object O1 does not understand message M, then it passes M to object O2” Forwarding and delegation differ in how they treat self : –In forwarding, O1 and O2 keep separate identities: a self call in O2 stays in O2 –In delegation, there is just one identity, namely O1: a self call in O2 will call O1 (delegation implies a common self)

59. Copyright 2002 by S. Haridi and P. Van Roy59 Forwarding I Account = {New class $ attr balance meth init balance := 0 end meth transfer(Amount) balance := @balance+Amount end meth getBal(B) B = @balance end end init }

60. Copyright 2002 by S. Haridi and P. Van Roy60 Forwarding II VerboseAccount = {New class $ from BaseObject attr forward:Account meth verboseTransfer(Amount) B in { self transfer(Amount)} { self getBalance(B)} {Browse B} end meth otherwise(M) {@forward M} end end init }

61. Copyright 2002 by S. Haridi and P. Van Roy61 The three approaches InheritanceDelegationForwarding Defined on classesDefined on objectsDefined on objects Common selfNo common selfNo common self Tight binding between original and derived object/class Loose binding Dynamic approaches: Can be defined at run-time Static approach: At class definition