1. Object-Oriented Programming CS 3360 Spring 2012 Sec 12.1-12.3, 12.5-12.6 Adapted from Addison Wesley’s lecture notes (Copyright © 2004 Pearson Addison Wesley)

2. 2 Outline Basics of object-oriented programming Design issues for OO languages Support for OOP in C++ Support for OOP in Java Implementation of OO constructs

3. 3 Object-Oriented Programming Paradigm evolution 1. Procedural: 1950s-1970s (procedural abstraction) 2. Data-oriented: early 1980s (data abstraction) 3. OOP: late 1980s (inheritance and dynamic binding) Support for reuse and hierarchical organization

4. 4 Categories of OOPLs 1. Pure OOP languages  Smalltalk 2. Extension to existing language  C++ (procedural and data-oriented)  Ada 95 (procedural and data-oriented)  CLOS (functional programming)

5. 5 Categories (Cont.) 3. New imperative with OO support  Eiffel  Java (based on C++)  C# (based on Java)

6. 6 Definitions of OOP ADTs are called classes. Class instances are called objects. A class that inherits is a derived class or a subclass. The class from which another class inherits is a parent class or superclass. Subprograms that define operations on objects are called methods.

7. 7 Definitions of OOP (Cont.) Calls to methods are called messages. The entire collection of methods of an object is called its message protocol or message interface. Messages have two parts--a method name and the destination object (receiver). In the simplest case, a class inherits all of the entities of its parent.

8. 8 Inheritance Inheritance can be complicated by access controls to encapsulated entities.  A class can hide entities from its subclasses.  A class can hide entities from its clients.  A class can also hide entities for its clients while allowing its subclasses to see them. Besides inheriting methods as is, a class can modify an inherited method.  The new one overrides the inherited one.  The method in the parent is overridden. Single vs. Multiple Inheritance One disadvantage of inheritance for reuse:  Creates interdependencies among classes that complicate maintenance

9. 9 Variables of Class There are two kinds of variables in a class: 1. Class variables - one/class 2. Instance variables - one/object There are two kinds of methods in a class: 1. Class methods – accept messages to the class 2. Instance methods – accept messages to objects

10. 10 Polymorphism A polymorphic variable can be defined in a class that is able to reference (or point to) objects of the class and objects of any of its descendants. When a class hierarchy includes classes that override methods and such methods are called through a polymorphic variable, the binding to the correct method MUST be dynamic. This polymorphism simplifies the addition of new methods.

11. 11 Abstract Methods and Classes An abstract method is one that does not include a definition (it only defines a protocol). An abstract class is one that includes at least one abstract method. An abstract class cannot be instantiated.

12. 12 Outline  Basics of object-oriented programming Design issues for OO languages Support for OOP in C++ Support for OOP in Java Implementation of OO constructs

13. Design Issues for OOP D1: Exclusivity of Objects D2. Are subclasses subtypes? D3. Implementation and Interface Inheritance D4. Type Checking and Polymorphism D5. Single and Multiple Inheritance D6. Allocation and De-allocation of Objects D7. Dynamic and Static Binding 13

14. 14 Design Issues D1: Exclusivity of Objects a. Everything is an object  Advantage - elegance and purity uniformity  Disadvantage - slow operations on simple objects (e.g., float) b. Add objects to an imperative typing system  Advantage - fast operations on simple objects  Disadvantage - results in a confusing type system (two kinds of entities)

15. 15 D1: Exclusivity of Objects (cont’d) c. Include an imperative-style typing system for primitives but make everything else objects  Advantage - fast operations on simple objects and a relatively small typing system  Disadvantage - still some confusion because of the two type systems

16. 16 Design Issues (cont’d) D2. Are subclasses subtypes?  Does an “ is-a ” relationship hold between a parent class object and an object of the subclass?

17. 17 Design Issues (Cont.) D2. Are subclasses subtypes?  Does an “ is-a ” relationship hold between a parent class object and an object of the subclass?  Subclasses are not subtypes! See extra-credit assignment: due Tuesday February, 14.

18. 18 Design Issues (cont’d) D3. Implementation and Interface Inheritance  If only the interface of the parent class is visible to the subclass, it is interface inheritance Disadvantage - can result in inefficiencies  If both the interface and the implementation of the parent class is visible to the subclass, it is implementation inheritance Disadvantage - changes to the parent class require recompilation of subclasses, and sometimes even modification of subclasses

19. D3. Implementation and Interface Inheritance (cont’d) The problems caused by multiple inheritance of classes result from potential conflicts among the various implementations of common methods in the inheritance chain. But suppose you knew that the classes you were inheriting from were pure abstract classes with no implementation?  In that case, multiple-inheritance wouldn't cause any problems because there would be no implementations to cause conflicts. This is what interfaces provide: a way to inherit just a set of method and property specifications with no implementation to worry about and no problem inheriting from as many interfaces as you need. 19

20. 20 Design Issues (cont’d) D4. Type Checking and Polymorphism  Polymorphism may require dynamic type checking of parameters and the return value. Dynamic type checking is costly and delays error detection.  If overriding methods are restricted to having the same parameter types and return type, the checking can be static.

21. 21 Design Issues (cont’d) D5. Single and Multiple Inheritance  Disadvantages of multiple inheritance: Language and implementation complexity (in part due to name collisions) Potential inefficiency - dynamic binding costs more with multiple inheritance (but not much)  Advantage: Sometimes it is extremely convenient and valuable

22. 22 Design Issues (cont’d) D6. Allocation and deallocation of objects  From where are objects allocated? If they all live in the heap, references to them are uniform Simplifies assignment - dereferencing can be implicit  Is deallocation explicit or implicit?

23. 23 Design Issues (cont’d) D6. Allocation and deallocation of objects  From where are objects allocated? If they all live in the heap, references to them are uniform Simplifies assignment - dereferencing can be implicit  Is deallocation explicit or implicit? In C++ it is In Java it is not (garbage collector) Other differences exist between the memory models of the two languages

24. 24 Design Issues (Cont.) D7. Dynamic and static binding  Should ALL binding of messages to methods be dynamic? If none are, you lose the advantages of dynamic binding If all are, it is inefficient

25. 25 Design Issues (Cont.) D7. Dynamic and static binding  Should ALL binding of messages to methods be dynamic? If none are, you lose the advantages of dynamic binding If all are, it is inefficient  No clear answer to that, except that when using polymorphism and overridden methods, static binding will not always be able to detect errors

26. 26 Outline  Basics of object-oriented programming  Design issues for OO languages Support for OOP in C++ Support for OOP in Java Implementation of OO constructs

27. Group activities: Jigsaw! 40 students Division of the topics between:  Support for OOP in C++  Support for OOP in Java & Implementation of OOP constructs 20 students in each: 5 teams of 4  Count 1-10  1-5: topic 1  6-10: topic 2 27

28. Group activities: Jigsaw! Objectives In each team:  One gatekeeper and all notekeepers Objectives:  Understand your own topic  Design a short presentation of it intended to your classmates and me  Make sure to include examples to illustrate each point 28

29. Group activities: Jigsaw! How? The rest of today’s session On Thursday:  Quiz on your own topic  Work in recomposed teams (2 topics per team) On Tuesday:  Quiz on both topics 29

30. 30 Support for OOP in C++ General characteristics:  Mixed typing system  Constructors and destructors  Elaborate access controls to class entities

31. 31 Support for OOP in C++ Inheritance  A class need not be the subclass of any class  Access controls for members are 1. Private (visible only in the class and friends) (disallows subclasses from being subtypes) 2. Public (visible in subclasses and clients) 3. Protected (visible in the class and in subclasses, but not clients)

32. 32 Support for OOP in C++ Inheritance (continued)  In addition, the subclassing process can be declared with access controls (private or public), which define potential changes in access by subclasses a. Private derivation - inherited public and protected members are private in the subclasses b. Public derivation - public and protected members are also public and protected in subclasses

33. 33 Example class base_class { private: int a; float x; protected: int b; float y; public: int c; float z; }; class subclass_1 : public base_class { … }; // - b and y are protected and c and z are public class subclass_2 : private base_class { … }; // - b, y, c, and z are private, and no derived // class has access to any member of base_class

34. 34 Support for OOP in C++ Reexportation  A member that is not accessible in a subclass (because of private derivation) can be declared to be visible there using the scope resolution operator ( :: ), e.g., class subclass_3 : private base_class { base_class :: c; … }

35. 35 Support for OOP in C++ Reexportation (continued)  One motivation for using private derivation: A class provides members that must be visible, so they are defined to be public members; a derived class adds some new members, but does not want its clients to see the members of the parent class, even though they had to be public in the parent class definition

36. 36 Support for OOP in C++ Multiple inheritance is supported  If there are two inherited members with the same name, they can both be referenced using the scope resolution operator (::)

37. 37 Support for OOP in C++ Dynamic binding  A method can be defined to be virtual, which means that they can be called through polymorphic variables and dynamically bound to messages  A pure virtual function has no definition at all  A class that has at least one pure virtual function is an abstract class

38. 38 Support for OOP in C++ Evaluation  C++ provides extensive access control (unlike Smalltalk)  C++ provides multiple inheritance  In C++, the programmer must decide at design time which methods will be statically bound and which must be dynamically bound Static binding is faster!  Smalltalk type checking is dynamic (flexible, but somewhat unsafe)  Because of interpretation and dynamic binding, Smalltalk is ~10 times slower than C++

39. 39 Outline  Basics of object-oriented programming  Design issues for OO languages  Support for OOP in C++ Support for OOP in Java Implementation of OO constructs

40. 40 Support for OOP in Java Because of its close relationship to C++, we focus on the differences from that language General Characteristics  All data are objects except for the primitive types  All primitive types have wrapper classes that store one data value  All objects are heap-dynamic, are referenced through reference variables, and most are allocated with new

41. 41 Support for OOP in Java Inheritance  Single inheritance only, but there is an abstract class category that provides some of the benefits of multiple inheritance ( interface )  An interface can include only method declarations and named constants, e.g., public class Clock extends Applet implements Runnable { … }  Methods can be final.

42. 42 Support for OOP in Java Dynamic binding  In Java, all messages are dynamically bound to methods, unless the method is final (means it cannot be overridden; therefore, dynamic binding serves no purpose)

43. 43 Support for OOP in Java Encapsulation  Two constructs, classes and packages  Packages provide a container for classes that are related (can be named or unamed)  Entities defined without a scope (access) modifier have package scope, which makes them visible throughout the package in which they are defined - they go in the unnamed package Every class in a package is a friend to the package scope entities elsewhere in the package So, package scope is an alternative to the friends of C++

44. 44 Outline  Basics of object-oriented programming  Design issues for OO languages  Support for OOP in C++  Support for OOP in Java Implementation of OO constructs

45. 45 Implementing OO Constructs Storage structure of instance variables  Class instance records (CIRs) store the state of an object  The CIR for a subclass adds its new fields to the parent CIR. Dynamic bindings of messages to methods  Virtual Method Tables (VMTs) are used for dynamic binding.

46. 46 Dynamic Binding (Dispatch) class Point { private int x, y; public Point(int x, int y) { this.x = x; this.y = y; } public int getX() { return x; } public int getY() { return y; } } class ColoredPoint extends Point { private Color color; public ColoredPoint(int x, int y, Color c) { super(x, y); color = c; } public Color getColor() { return color; } } xy…xy… x y color … CIR for ColoredPoint CIR for Point

47. 47 super: vmt: … Point.class getX: getY: … class: x: 10 y: 20 color: p: Color.RED super: vmt: … ColoredPoint.class Dynamic Binding (Cont.) ColoredPoint p = new ColoredPoint(10,20,Color.RED); p.getColor(); p.getX(); Object.class super: vmt: … getColor: …