1. OOPs Object oriented programming

2. Abstract data types  Representationof type and operations in a single unit  Available for other units to create variables of the type  Possibility of hiding data structure of type and implementation of operations

3. Limitations of ADT and OOP extensions  Software reuse: ADTs too rigid -> inheritance  No structure to collections of ADTs -> inheritance OOP provides class hierarchies

4. The three* hierarchies of OOP  Inheritance: 1 - n  Instantiation 1 - n  Composition 1 - n superclass subclass class instance object instance variable * Not including interfaces

5. Inheritance  Superclass – subclass Subclass inherits all methods, variables Subclass can add methods, variables Subclass can overwrite all methods, variables -> increased reusability -> structure collections of classes

6. Access to variables and methods  ADTs – public (global scope) or private (class scope)  Objects - public or private -plus protected (class plus subclasses)? Design decision: info hiding vs efficiency  Java adds package scope

7. Inheritance rules  Single inheritance (Smalltalk) – subclass has only one superclass; classes form an inheritance tree  Multiple inheritance (C++) – subclass can have multiple superclasses  Single inheritance plus interfaces (Java)

8. Need for multiple inheritance  ‘orthogonal’ properties – the ‘diamond’ problem Vehicle GMVehicleKiaVehicle GMCarGMSUVKiaCarKiaSUV Vehicle CarSUV GMCarGMSUVKiaCarKiaSUV Car, SUV properties repeated Manufacturer properties repeated

9. Using multiple inheritance Vehicle KiaVehicleGMVehicleCarSUV GMCarGMSUVKiaCarKiaSUV

10. Problems of multiple inheritance  Identifier conflict: Class Super1 int x, y Class Super2 double x, z Class Sub extends Super1, Super2 Which x?

11. Interfaces solve the multiple inheritance problem  No variables in interfaces  No method implementations in interfaces – only protocols BUT  Weaker inheritance – no gain in code reuse

12. Type checking  none (Smalltalk typeless) message compatibility  subclasses are subtypes* type compatibility – object of subtype can be assigned to identifier declared of superclass type dynamic type checking provides polymorphism * note exceptions, e.g., C++

13. Polymorphism in method calls class Super method x() class Sub1 method x() class Sub3 method x() class Sub2 Super a,b,c,d; a = new Super(); b = new Sub1(); c = new Sub2(); d = new Sub3(); a.x(); b.x(); c.x(); d.x();

14. Polymorphism means dynamic type checking  class of object must be determined at run time methods bound to messages dynamically parameters type checked dynamically BUT  protocol can be verified statically -> purpose of abstract methods

15. Forced static binding  if a method cannot be overridden, it can be statically bound C++ assumes methods cannot be overridden -> statically bound – virtual keyword causes dynamic binding Java (and Objective C) assumes methods can be overridden -> dynamic binding – final keyword allows static binding

16. Implementing dynamic method invocation Superclass method table (VMT) -methA -methB Subclass method table (VMT) -methA -methC Ref to parent VMT Superclass var1; var1 = new Subclass(); var1.methA(); var1.methB(); var1.methC(); // compile error var1 Instance vars; Ref to class VMT

17. Allocation and de-allocation  What kinds of object memory allocation? Static Stack-dynamic Heap-dynamic  Heap reclamation Programmer control Garbage collection C++Smalltalk,Java X X

18. C++  Access: Classes private, public Members private, public, protected  Extending class can change access Override access to members in parent Valuable for ‘narrowing’ access polymorphism problem List StackQueue Remove some access

19. C++  Inheritance – partial – no single hierarchy  Efficient but complex

20. Java  Closer to pure object language than C++ No functions Dynamic by default One hierarchy of classes BUT  Imperative statements  Primitive data types are not objects

21. Another ‘object’ model  Property lists / attribute-value pairs E.g., Lisp symbols: property list E.g., Javascript objects: hash table Properties are typeless – data and methods Set of properties is dynamically varying Ideally suited to tabulation – visual programming Are they objects? ADTs? Variant records?