1. CSCI 383 Object-Oriented Programming & Design Lecture 17 Martin van Bommel

2. Subtype, Subclass and Substitution The distinction between subtype and subclass is important because of their relationship to substitution Recall the argument that asserted a child class has the same behavior as the parent, and thus a variable declared as the parent class should in fact be allowed to hold a value generated from a child class But does this argument always hold true?

3. Subtypes What is wanted here is something like the following substitution principle: If for each object o 1 of type S there is an object o 2 of type T such that for all programs P defined in terms of T the behavior of P is unchanged when o 1 is substituted for o 2 then S is a subtype of T. [Liskov 1988]

4. What is a type? What do we mean when we use the term (data) type in describing a programming language? A set of values (the type int, for example, describes - 2147483648 to 2147483647) A set of operations (we can do arithmetic on ints, not on booleans) A set of properties (if we divide 8 by 5 we are not surprised when the result is 1, and not 1.6) What about when we consider classes (or interfaces) as a system for defining types?

5. The Problem of Defining Types Consider how we might define a Stack ADT

6. The Problem of Defining Types Notice how the interface itself says nothing about the LIFO property, which is the key defining feature of a stack. Is the following a stack? This class definition satisfies the Stack interface but does not satisfy the properties we expect for a stack, since it violates the LIFO property for all but the most recent item placed into the stack

7. The Definition of Subtype From this example we see that the properties that are key to the meaning of the Stack are not specified by the interface definition. It is not that we were lazy; Java (like most other languages) gives us no way to specify the properties that an interface should satisfy

8. The Definition of Subtype So now we can better understand the concept of a subtype A subtype preserves the meaning (purpose, or intent) of the parent The problem is that meaning is extremely difficult to define. Think about how to define the LIFO characteristics of the stack

9. The Substitution Paradox There is a curious paradox that lies at the heart of most strongly typed object-oriented programming languages Substitution is permitted, based on subclasses. That is, a variable declared as the parent type is allowed to hold a value derived from a child type Yet from a semantic point of view, substitution only makes sense if the expression value is a subtype of the target variable If substitution only makes sense for subtypes and not for all subclasses, why do programming languages based the validity of assignment on subclasses?

10. The Undecidability of the Subtype Relationship It is trivial to determine if one class is a subclass of another It is extremely difficult to define meaning (think of the Stack ADT), and even if you can it is almost always impossible to determine if one class preserves the meaning of another One of the classic corollaries of the halting problem is that there is no procedure that can determine, in general, if two programs have equivalent behavior There is simply no way that a compiler can ensure that a subclass created by a programmer is indeed a subtype

11. Is This a Problem? What does it take to create a subclass that is not a subtype? The new class must override at least one method from the parent It must preserve the type signatures But it must violate some important property of the parent Is this common? Not likely. But it shows you where to look for problem areas

12. Subtyping in C++ Subtyping in C++ is provided through inheritance Suppose a class Circle is derived from a class Shape. Then, as mentioned before, a Circle object can be implicitly converted into a Shape object Circle circle; Shape shape = circle; This is called upcasting in C++ because you’re moving up in the class hierarchy What happens here is that shape loses all information about circle which isn’t contained within the Shape class (e.g., a radius data member). This is known as object slicing

13. Static and Dynamic Behavior We are able to derive new types from existing types We can upcast from a derived type to its base type This is useful because it allows us to share some code However, it really does not give us the polymorphism we want to extract from similar types

14. Static and Dynamic Behavior For example, suppose we have the following inheritance hierarchy class Shape {... void draw(void) const;... }; class Circle:public Shape{class Rectangle:public Shape{...void draw(void) const;...};

15. Static and Dynamic Behavior Suppose we declared an array of shapes like this Shape* shapeList[2]; shapeList[0] = new Circle(...); // Upcast to Shape* shapeList[1] = new Rectangle(...); // Upcast to Shape* We might want a function to draw all of our shapes in the shape list void draw(int numShapes, Shape* shapeList[]) { for(int i=0; i<numShapes; i++) shapeList[i]->draw(); }

16. Static and Dynamic Behavior Even though we created a Circle object and a Rectangle object, drawShapes only sees them as generic Shape objects There are different ways of solving this problem, and we’ll look at a couple of them

17. Type Fields One way to solve this polymorphism problem is to manually store the type within every Shape, Circle, or Rectangle object We could do this by defining an enumerated type, and marking each object in its constructor with its proper type However, this is very error prone and tends to lead to a lot of switch statements and casting throughout your code

18. Static vs. Dynamic Type So far, we haven’t been able to break the bounds of the declaration type, or the static type, of an object The declared type of an object or an object pointer has been determining which method will be called The compiler pays no attention to the true type of the object – which is the type we provided when we allocated it with new. This is also called the object’s dynamic type

19. Static and Dynamic Much of the power of object-oriented languages derives from the ability of objects to change their behavior dynamically at run time In Programming languages Static almost always means fixed or bound at compile time, and cannot thereafter be changed Dynamic almost always means not fixed or bound until run time, and therefore can change during the course of execution

20. Static and Dynamic Typing In a statically typed programming language, variables have declared types – fixed at compile time (e.g., C++, Java, Pascal) In a dynamically typed programming language, a variable is just a name. Types are associated with values, not variables. A variable can hold different types during the course of execution (e.g., Smalltalk, Python)

21. Arguments For and Against Static and Dynamically typed languages have existed as long as there have been programming languages. Arguments for and against: Static typing allows better error detection, more work at compile time and hence faster execution time Dynamic typing allows greater flexibility, easier to write (for example, no declaration statements) Both arguments have some validity, and hence both types of languages will continue to exist in the future

22. The Polymorphic Variable The addition of object-oriented ideas in statically typed languages adds a new twist. Recall the argument for substitution: an instance of a child class should be allowed to be assigned to a variable of the parent class

23. Static Class and Dynamic Class In a statically typed language we say the class of the declaration is the static class for the variable, while the class of the value it currently holds is the dynamic class Most statically typed OO languages constrain the dynamic class to be a child class of the static class Animal pet; Dog fido; Cat fluffy; pet = fido; // legal pet = fluffy; // legal fido = pet; // not legal!

24. Importance of Static Class In a statically typed object-oriented language, the legality of a message is determined at compile time, based on the static class A message can produce a compile error, even if no run- time error could possibly arise class Animal {}; class Dog : Animal { void bark() { std::cout << "woof"; } }; Animal *pet = new Dog; pet->bark();// generates error, Animals don’t bark

25. Binding Times The binding time of a function call is when the call is bound to a specific function implementation There generally are two binding times: static binding and dynamic binding Static binding (also known as early binding) is when the function choice is based on the characteristics of the variable (i.e., the type of the variable) Static binding generally takes place at compile time Function overloading and overriding in C++ are examples of static binding

26. Binding Times Dynamic binding (also known as late binding) is when the function choice is based on the dynamic characteristics of the variable (i.e., the type of the data in the variable) Dynamic binding is deferred until run time In a previous example, if one sends a draw message to an instance of Rectangle or Circle, one would want the appropriate implementation of draw to be executed However, if at compile time one knows only that the receiving object is “an instance of a Shape subclass, to be determined at run time”, static binding cannot be used. In this case, dynamic binding is used Dynamic binding is a powerful but dangerous tool To eliminate the danger of run time errors in C++, dynamic binding has been limited to virtual functions

27. Virtual Functions The way to retain the behavior of the instantiated type is through the use of virtual functions To declare a method to be a virtual function, you simply use the virtual keyword when declaring the method in the class definition When you call a function, it will check the dynamic type of the object before choosing which function to call – this process is reification

28. Virtual Functions For example, we could declare our Shape, Circle, and Rectangle classes as follows class Shape {... virtual void draw() const;... }; class Circle : public Shape {class Rectangle : public Shape {...... virtual void draw() const; virtual void draw() const;......};

29. Virtual Functions Now we get the polymorphic behavior we want Shape* shapeList[maxShapes]; shapeList[0] = new Circle(...); shapeList[1] = new Rectangle(...); shapeList[0]->draw(); // Calls Circle::draw() shapeList[]->draw(); // Calls Rectangle::draw()

30. Virtual Functions It is important that you declare the function to be virtual throughout your class hierarchy, or its behavior can be quite unexpected Virtual and non-virtual method can call each other Overloaded operator functions can be virtual functions A constructor cannot be a virtual function because it needs to know the exact type to create However, a destructor can be declared as virtual, and generally should be virtual functions may not seem significant at first, but they enable a ton of code reuse when using class hierarchies