1. OO as a language for acm l OO phrase l Mental model of key concepts

2. History l Birth of OO dates to Simula 67 l 35 years ago l Simula introduced all the fundamental OO concepts

3. History l Simula (and OO) are rooted in abstract data types, separation of concerns, classification schemes dating from Aristotle, discrete event simulation l Formal foundations in behavioral subtyping (LSP), object calculi l Aspect-oriented programming (modularity in more than one dimension)

4. Modules Class  Ada83 package spec that defines a record type & associated operations Object  instance of record type A

5. Data Attribute  Record field public (+) private (-) protected (#) A

6. Code Operation  subprogram spec Also public (+), protected (#), private (-) Method  subprogram body Signature, e.g. “ m (p: Integer) ” Overloading Constructor Destructor A

7. ‘ Generics ’ Template class  generic package A parameters

8. Phrase book, page 1 l Class l Attribute l Public l Private l Protected l Operation l Method l Signature

9. Phrase book, page 2 l Overloading l Constructor l Destructor l Class instance = object l Template class

10. Calls x: A; … x.m(i); Declared type Remaining arguments Target object A m(a: int)

11. Interfaces … concrete classes Interface client operations only Abstract class some attributes some operations, some methods Concrete class attributes methods A > B C

12. Phrase book, page 3 l Declared type l Target object l Interface l Abstract class l Concrete class

13. “ Contracts ” Precondition Postcondition Invariant A

14. Interface inheritance Generalization Superinterface A Subinterface B A B

15. B inherits the operations of A It may also override them  And may add operations of its own m (a: int) n (x: int) : float o () n (a: int): float Interface inheritance A B

16. Inheritance “ math ”

17. Liskov Substitution Principle n (x: int) : float l Precondition of , must require the same or less than the precondition of  l Postcondition of , must deliver the same or more than the postcondition of  We can test for this by “ inheriting ” all test cases

18. All B ’ s are A ’ s Anywhere we use an A, we use a B Substitutability A B

19. Interface inheritance A superinterface may also have more than one subinterface B A C

20. Phrase book, page 4 l Interface inheritance l Superinterface l Subinterface l Overriding

21. Phrase book, page 5 l Generalization l Liskov Substitution Principle (LSP) l Precondition l Postcondition l Invariant

22. Interface implementation Realization Class B “ realizes ” interface A In accordance with LSP A B

23. Multiple implementations More than one class may “ realize ” a given interface Partial implementation by abstract subclass Full implementation by concrete subclass A BC D

24. Implementation inheritance Superclass Subclass Still in accordance with LSP C D

25. Implementation inheritance A superclass may have more than one subclass D C E

26. Polymorphism x: A = new B; … x.m(i); Variable may reference any object of its declared type or any of its subtypes (polymorphism) Run time type of an object is set when it is created, and never changes Run-time type Declared type A BC D m(a: int)

27. Polymorphism for each display element element.draw() end DisplayElement importance : int xOrigin : CoordinateValue yOrigin : CoordinateValue draw() highlight() hide() NonTextualElement highlight() PrimitiveNonTextualElement draw() highlight() AltitudeTape width : GraphicsDistance height : GraphicsDistance colorScheme : ColorScheme displayedValue : Altitude draw() getDisplayedValue() : Altitude setDisplayedValue(altitude : Altitude) AirspeedTape draw() getDisplayedValue() : Airspeed setDisplayedValue(airspeed : Airspeed) Compass radius : GraphicsDistance colorScheme : ColorScheme displayedValue : Heading draw() getDisplayedValue() : Heading setDisplayedValue(heading : Heading) TextualElement width : GraphicsDistance height : GraphicsDistance displayedValue : String draw() highlight() getDisplayedValue() : String setDisplayedValue(string : String) width : GraphicsDistance height : GraphicsDistance colorScheme : ColorScheme displayedValue : Altitude

28. Dynamic dispatch Polymorphism + multiple methods  dispatch l All display elements have a draw operation l We need to call the right implementation of draw l Right = the one that matches the run time type associated with the object when it was created

29. Dynamic Dispatch Call to draw is semantically equivalent to a case statement for each display element case of display element ’ s run time type case (AltitudeTape) call AltitudeTape.draw() case (AirspeedTape) call AirspeedTape.draw() case (Compass) call Compass.draw() case (PrimitiveNonTextualElement) call PrimitiveNonTextualElement.draw() case (TextualElement) call TextualElement.draw() end

30. l In general, method selection is a function of the run time type and the method signature l Conceptually there is a single dispatch routine for all calls containing a pair of nested case statements case of target object ’ s run time type - (1) case ( ) case of method signature - (2) case ( ) call defined by -- (3) end In practice, calls to this universal dispatch method are ‘ inlined ’ at the point of call Dynamic Dispatch

31. Typically implemented using “ dispatch tables ” l Small, fixed overhead l At the point of call: (1) get the dispatch table associated with the target object, (2) index it by a number associated with the method signature, and (3) invoke the method Dynamic Dispatch … dispatch table for type targetObject run time type

32. Phrase book, page 6 l Realization l Polymorphism l Declared type l Run-time type l Dynamic dispatch l Dispatch table

33. Multiple interface inheritance  More than one superinterface  Inherited elements represent only specs  No code or data BA C

34. Multiple implementation inheritance  More than one superclass  Inherited elements represent code and data in addition to specs  Inherited elements may reference one another BA C

35. Phrase book, page 7 l Multiple interface inheritance l Multiple implementation inheritance

36. Whole-part associations Aggregation XY Composition Whole Part XY

37. Delegation A B Delegate m(a: int) Delegation, e.g., of all calls to B::m(int) to A::m(int) “Do it yourself” inheritance

38. Inheritance + delegation  Single inheritance + delegation  “Inheritance of implementation from” one superclass  “Delegation to” the implementation of the other BA C

39. Phrase book, page 8 l Association l Aggregation l Composition l Delegation

40. Other related concepts l Use cases l Patterns l Aspects, join points, aspect weaving

41. Primary advantages of OO l Improved coupling/cohesion l Isolation of likely future changes l Product families l Reuse - of specifications, code, test cases l Explicit specification of when one component is substitutable for another l Explicit criteria for testing this (LSP)