1. C. Varela; Adapted from S. Haridi and P. Van Roy1 Object-Oriented Programming Inheritance (VRH 7.3-4) Object System Implementation/Java(VRH 7.6-7) Carlos Varela RPI Adapted with permission from: Seif Haridi KTH Peter Van Roy UCL

2. C. Varela; Adapted from S. Haridi and P. Van Roy2 Overview What is object-oriented programming? –Stateful (imperative) model (revisited) –Objects –Classes –Interfaces Inheritance Polymorphism Static and dynamic binding Multiple Inheritance Reflection Relationship to Other Programming Models Active Objects

3. C. Varela; Adapted from S. Haridi and P. Van Roy3 Classes in Oz (simplified syntax) A class is a statement class  ClassVariable  attr  AttrName1  :  AttrNameN  meth  Pattern1   Statement  end : meth  PatternN   Statement  end end

4. C. Varela; Adapted from S. Haridi and P. Van Roy4 Classes in Oz (Example) The class Counter has the syntactic form class Counter attr val meth display {Browse @val} end meth inc(Value) val := @val + Value end meth init(Value) val := Value end end

5. C. Varela; Adapted from S. Haridi and P. Van Roy5 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 display} {C inc(1)} {C display} Object interface is as a procedure of one argument, which expects a record representing a method

6. C. Varela; Adapted from S. Haridi and P. Van Roy6 Classes as functors functor Counter export inc:Inc display:Display init:Init defineS S proc {Init init(I)} S = {NewCell I} end proc {Inc Value} S := @S + Value end proc {Display} {Browse @S} end end

7. C. Varela; Adapted from S. Haridi and P. Van Roy7 Pattern of use fun {New Functor Init} M in [M] = {Module.apply [Functor]} {M.init Init} M End declare C1 C2 C1 = {New Counter init(0)} C2 = {New Counter init(100)} {C1.inc 1} {C1.display} {C2.inc 10} {C2.display} Generic function to create objects from functors Object interface is a record with procedure values inside fields

8. C. Varela; Adapted from S. Haridi and P. Van Roy8 Classes as (higher-order) procedures fun {Counter} S proc {Inc inc(Value)} S := @S + Value end proc {Display display} {Browse @S} end S proc {Init init(I)} S = {NewCell I} end D = o(inc:Inc display:Display init:Init) in proc{$ M} {D.{Label M} M} end end

9. C. Varela; Adapted from S. Haridi and P. Van Roy9 Pattern of use fun {New Class InitialMethod} O = {Class} in {O InitialMethod} O end declare C = {New Counter init(0)} {C display} {C inc(1)} {C display} Generic function to create objects from classes (procedures) Object interface is a procedure of one argument, which expects a record representing a message.

10. C. Varela; Adapted from S. Haridi and P. Van Roy10 Object-oriented programming Supports –Encapsulation –Compositionality –Instantiation Plus –Inheritance

11. C. Varela; Adapted from S. Haridi and P. Van Roy11 Inheritance Programs can be built in hierarchical structure from ADT’s that depend on other ADT’s (Components) Object-oriented programming (inheritance) is based on the idea that ADTs have so much in common For example, sequences (stacks, lists, queues) Object oriented programming enables building ADTs incrementally, through inheritance An ADT can be defined to inherit from another abstract data type, substantially sharing functionality with that abstract data type Only the difference between an abstract datatype and its ancestor has to be specified

12. C. Varela; Adapted from S. Haridi and P. Van Roy12 Classes as incremental ADTs 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

13. C. Varela; Adapted from S. Haridi and P. Van Roy13 Inheritance Inheritance should be used as a way to specialize a class while retaining the relationship between methods In this way it is a just an extension of an ADT The other view is inheritance is just a (lazy) way to construct new abstract data types! No relationships are preserved general class specialized class

14. C. Varela; Adapted from S. Haridi and P. Van Roy14 Inheritance class Account attr balance:0 meth transfer(Amount) balance := @balance+Amount end meth getBal(B) B = @balance end A={New Account transfer(100)}

15. C. Varela; Adapted from S. Haridi and P. Van Roy15 Inheritance II Conservative extension class VerboseAccount from Account meth verboseTransfer(Amount)... end The class VerboseAccount has the methods: transfer, getBal, and verboseTransfer

16. C. Varela; Adapted from S. Haridi and P. Van Roy16 Inheritance II Non-Conservative extension class AccountWithFee from VerboseAccount attr fee:5 meth transfer(Amount)... end The class AccountWithFee has the methods: transfer, getBal, and verboseTransfer The method transfer has been redefined (overridden) with another definition

17. C. Varela; Adapted from S. Haridi and P. Van Roy17 Inheritance II Non-Conservative extension class AccountWithFee from VerboseAccount attr fee:5 meth transfer(Amount)... end Account VerboseAccount AccountWithFee

18. C. Varela; Adapted from S. Haridi and P. Van Roy18 Polymorphism The ability for operations to take objects (instances) of different types. For example, the transfer method can be invoked in account object instances of three different classes. The most specific behavior should be executed. Account VerboseAccount AccountWithFee

19. C. Varela; Adapted from S. Haridi and P. Van Roy19 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

20. C. Varela; Adapted from S. Haridi and P. Van Roy20 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

21. C. Varela; Adapted from S. Haridi and P. Van Roy21 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.

22. C. Varela; Adapted from S. Haridi and P. Van Roy22 Inheritance class Account attr balance:0 meth transfer(Amount) balance  @balance+Amount end meth getBal(B) B = @balance end A={New Account transfer(100)}

23. C. Varela; Adapted from S. Haridi and P. Van Roy23 Inheritance II Conservative extension class VerboseAccount from Account meth verboseTransfer(Amount) { self transfer(Amount)} {Browse @balance} end The class VerboseAccount has the methods: transfer, getBal, and verboseTransfer

24. C. Varela; Adapted from S. Haridi and P. Van Roy24 Inheritance II Non-Conservative extension class AccountWithFee from VerboseAccount attr fee:5 meth transfer(Amount) VerboseAccount, transfer(Amount - @fee) end The class AccountWithFee has the methods: transfer, getBal, and verboseTransfer The method transfer has been redefined (overridden) with another definition

25. C. Varela; Adapted from S. Haridi and P. Van Roy25 Inheritance II 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 the invariants the programmer depends on Account getBalance(B); transfer(S); getBalance(B1) => B1 = B+S

26. C. Varela; Adapted from S. Haridi and P. Van Roy26 Inheritance II 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 the invariants the programmer depends on AccountWithFee getBalance(B); transfer(S); getBalance(B1) => B1 = B+S-@fee

27. C. Varela; Adapted from S. Haridi and P. Van Roy27 Inheritance III 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 methods (attributes and features) available in a class C (i.e. visible) are defined through a precedence relation on the methods that appear in the class hierarchy based on the overriding relation: –A method in a class C overrides any method, with the same label, in any super class of C.

28. C. Varela; Adapted from S. Haridi and P. Van Roy28 SuperClass relation C SuperClass relation is directed and acyclic.

29. C. Varela; Adapted from S. Haridi and P. Van Roy29 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.

30. C. Varela; Adapted from S. Haridi and P. Van Roy30 Inheritance relation C m m m A (valid hierarchy) (invalid hierarchy) m

31. C. Varela; Adapted from S. Haridi and P. Van Roy31 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}

32. C. Varela; Adapted from S. Haridi and P. Van Roy32 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 There are two init methods visible for CustomerAccount This is illegal

33. C. Varela; Adapted from S. Haridi and P. Van Roy33 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

34. C. Varela; Adapted from S. Haridi and P. Van Roy34 Controlling visibility Visibility is the control given to the user to limit access to members of a class (attributes, methods and features) Each member 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

35. C. Varela; Adapted from S. Haridi and P. Van Roy35 Public and private scopes in ADTs A private member is one which is only visible in the object instance (it is used for implementing the ADT) The object instance can see all the private members in its class and its super classes A public member is visible anywhere in the program It is part of the interface of the ADT In Oz (and Smalltalk) attributes are private and methods are public (the default rule) In Java and C++ private has another meaning

36. C. Varela; Adapted from S. Haridi and P. Van Roy36 The meaning of Private C SubC SubSubC I1I4I2I3 Instances Class Hierarchy

37. C. Varela; Adapted from S. Haridi and P. Van Roy37 The meaning of Private C SubC SubSubC I1I4I2I3 Instances Class Hierarchy According to Smalltalk and Oz All private members in this region are visible to I3

38. C. Varela; Adapted from S. Haridi and P. Van Roy38 The meaning of Private C SubC SubSubC I1I4I2I3 Instances Class Hierarchy According to C++ and Java All private members in this region are visible to I3

39. C. Varela; Adapted from S. Haridi and P. Van Roy39 Public and private scopes in ADTs In Oz (and Smalltalk) attributes are private and methods are public It is possible in Oz to make a method private within a class Using a variable identifier as a method head will make the method local to the class The variable is automatically bound to a unique name class C meth A(...)... end.... end

40. C. Varela; Adapted from S. Haridi and P. Van Roy40 Public and private scopes in ADTs In Oz (and Smalltalk) attributes are private and methods are public It is possible in Oz to make a method private within a class Using a variable identifier as a method head will make the method local to the class The variable is automatically bound to a unique name ! is an escape character, !A means escape the class scope class C meth A(...)... end.... end A local A = {NewName} in class C !A(...) meth !A(...)... end.... end

41. C. Varela; Adapted from S. Haridi and P. Van Roy41 Programming techniques First class messages (higher order programming) Parameterized classes Use of multiple inheritance

42. C. Varela; Adapted from S. Haridi and P. Van Roy42 Techniques of Higher order programming Control abstractions class HigherOrderControl meth forAll(ListObjects M) for O in ListObjects do {O M} end end... end This technique allows messages as parameters

43. C. Varela; Adapted from S. Haridi and P. Van Roy43 Techniques of Higher order programming Control abstractions class HigherOrderControl... meth nil skip end meth ’|’(M Ms) {self M} {self Ms} end C = {New class $ from HigherOrderControl Counter end init(0)} {C [inc(2) display inc(3) display]}

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

45. C. Varela; Adapted from S. Haridi and P. Van Roy45 Classes as First Class Values fun {MakeClassAccountWithFee Fee} class $ % Fee is in closure from Account meth init(Amount) Account,init(Amount-Fee) end Account={MakeClassAccountWithFee 100} {New Account init(1000)}

46. C. Varela; Adapted from S. Haridi and P. Van Roy46 Delegation and Forwarding Some object systems do not use inheritance (self) They use a notion known as delegation or forwarding Every class is an object Inheritance is implemented by forwarding messages the object cannot handle to a ”delegate” which behaves as a super-class Delegation preserves the ”self”, forwarding does not.

47. C. Varela; Adapted from S. Haridi and P. Van Roy47 Delegation example 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 }

48. C. Varela; Adapted from S. Haridi and P. Van Roy48 Delegation example (II) VerboseAccount = {New class $ from BaseObject attr delegate:Account meth verboseTransfer(Amount) { self transfer(Amount)} {Browse { self getBal($)}} end meth otherwise(M) {@delegate M} end end init } By changing the delegate, the ”inheritance” hierarchy can be modified at run- time.

49. C. Varela; Adapted from S. Haridi and P. Van Roy49 Multiple inheritance Multiple Inheritance is useful when an object has to be two different things in the same program (mixin inheritance) Example, assume we have graphical objects –Line, circle, etc –Composite graphical objects (groups) We use multiple inheritance to add the ability of grouping figures

50. C. Varela; Adapted from S. Haridi and P. Van Roy50 Class diagrams Figure Line Circle canvas x1, x2, y1, y2 canvas x, y, r init, move(X Y), display init, move(X Y), display LinkedList items init, add(O), forall(P) CompositeFigure init, move(X Y), display

51. C. Varela; Adapted from S. Haridi and P. Van Roy51 LinkedList Class class LinkedList attr items meth init items  nil end meth add(E) items  E|@items end meth forall(M) for O in @items do {O M} end end

52. C. Varela; Adapted from S. Haridi and P. Van Roy52 LinkedList (pure object) Java style class LinkedList attr item next meth init(item:E<=null next:N<=null) item  E next  N end meth add(E) next  {New LinkedList init(item:E next:@next)} end meth forall(M) if @elem\=null then {@item M} end if @next\=null then {@next forall(M)} end end

53. C. Varela; Adapted from S. Haridi and P. Van Roy53 Line class Line from Figure attr canvas x1 y1 x2 y2 meth init(Can X1 Y1 X2 Y2) canvas  Can x1  X1 y1  Y1 x2  X2 y2  Y2 end meth move(X Y) x1  @x1+X y1  @y1+Y x2  @x2+X y2  @y2+Y end meth display {@canvas create(line @x1 @y1 @x2 @y2)} end

54. C. Varela; Adapted from S. Haridi and P. Van Roy54 CompositeFigure class CompositeFigure from Figure LinkedList meth init LinkedList, init end meth move(X Y) {self forall(move(X Y))} end meth display {self forall(display)} end

55. C. Varela; Adapted from S. Haridi and P. Van Roy55 Use of single inheritance LinkedList elem, next init, add(O), forall(P) CompositeFigure init, move(X Y), display, add(O) Figure linkedList 1 1 association

56. C. Varela; Adapted from S. Haridi and P. Van Roy56 CompositeFigure class CompositeFigure from Figure attr figList meth init figList := {New LinkedList init} end meth add(F) {@figList add(F)} end meth move(X Y) {@figList forall(move(X Y))} end meth display {@figList forall(display)} end

57. C. Varela; Adapted from S. Haridi and P. Van Roy57 Multiple vs. Single inheritance With multiple inheritance a composite figure is also a linked list. In general use multiple inheritance in this case if you want all operations of linked list to be available With single inheritance a composite figure completely hides the linked list Use single inheritance if you want to hide the linked list functionality

58. C. Varela; Adapted from S. Haridi and P. Van Roy58 Rules for using inheritance Do not violate the substitution property. Programs working on objects of a given class should work on all the objects of its subclasses Do not use subclassing to fix a small problem. That is to say, do not patch up a class by making a subclass. The class hierarchy tends to get large and the program slower

59. C. Varela; Adapted from S. Haridi and P. Van Roy59 When does multiple inheritance work? Multiple inheritance works well when combining two completely independent abstractions Multiple inheritance does not work so well when abstractions have something in common Multiple inheritance creates conflicts when there is a shared class with mutable attributes Multiple inheritance creates conflicts when there are attribute or method names duplicated

60. C. Varela; Adapted from S. Haridi and P. Van Roy60 When are there conflicts? Multiple inheritance creates conflicts when there is a shared class with mutable attributes –Known as the implementation sharing problem –The constructor of the subclass may initialize the superclass multiple times. –Unless the inheritance hierarchy is carefully understood/analyzed Multiple inheritance creates conflicts when there are attribute or method names duplicated –Conflicting methods/attributes must be overriden/hidden in subclass. –Special syntax may enable access to specific superclass methods/attributes Person StudentStaff TA

61. C. Varela; Adapted from S. Haridi and P. Van Roy61 Reflection A system is reflective if it can inspect part of its execution state while it is running. Introspection only reads internal state, without modifying it (also called reification) Reflection enables modifying execution state, and thereby changing system semantics (e.g. Lisp)

62. C. Varela; Adapted from S. Haridi and P. Van Roy62 Meta Object Protocols Reflection applied to Object-Oriented systems The description of how an object system works at a basic level is called a Meta Object Protocol. The ability to change meta-object protocol is a powerful way to modify an object system For example, examine (or change) inheritance hierarchy while running Examine (or change) how inheritance works –How method lookup is done in the class hierarchy –How methods are called Applications in debugging, customizing, separation of concerns (aspects) Invented in the context of Common Lisp Object System (CLOS).

63. C. Varela; Adapted from S. Haridi and P. Van Roy63 Method Wrapping fun {TraceNew Class Init} Obj = {New Class Init} proc {TracedObject M} {Browse entering({Label M})} {Obj M} {Browse exiting({Label M})} end in TracedObject end An object created with TraceNew behaves identically to an object created with New, except method calls (except for calls to self ) are traced.

64. C. Varela; Adapted from S. Haridi and P. Van Roy64 Reflection (Introspection) in Java If permitted by security policy, the Java Reflection API can be used to: –Construct new class instances and arrays –Access and modify fields (attributes) of objects and classes –Invoke methods on objects and classes –Access and modify elements of arrays

65. C. Varela; Adapted from S. Haridi and P. Van Roy65 Reflection (Introspection) in Java The Java Reflection API consists of: –The class java.lang.Class –The interface java.lang.reflect.Member –The class java.lang.reflect.Field –The class java.lang.reflect.Method –The class java.lang.reflect.Constructor –The class java.lang.reflect.Array –The class java.lang.reflect.Modifier –The class java.lang.reflect.InvocationTargetException

66. C. Varela; Adapted from S. Haridi and P. Van Roy66 Reflection Applications (Java) Applications getting run-time information about objects, use: –getField[s] –getMethod[s] –getConstructor[s] Applications getting compile-time information about objects (at the level provided by class files), use: –getDeclaredField[s] –getDeclaredMethod[s] –getDeclaredConstructor[s]

67. C. Varela; Adapted from S. Haridi and P. Van Roy67 Exercises Do Java and C++ allow multiple inheritance? If so, how? If not, why? Does C++ enable reflection? If so, how? If not, why? Exercise VRH 7.9.2 (pg 567) Exercise VRH 7.9.3 (pg 567) Exercise VRH 7.9.4 (pg 567) Read VRH Sections 7.5 and 7.6