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

2. Fall 2010CSCI 383 Lecture 15 M. van Bommel 2 Abstract Idea of Inheritance Idea of inheritance is like a hierarchy of categories:

3. Fall 2010CSCI 383 Lecture 15 M. van Bommel 3 Practical Meaning of Inheritance Data members in the parent are part of the child Behaviors defined in the parent are part of the child Note that private aspects of the parent are part of the child, but are not accessible within the child class

4. Fall 2010CSCI 383 Lecture 15 M. van Bommel 4 Private, Public and Protected There are now three levels of visibility modifiers: public: accessible anywhere private: accessible only within the class definition (but memory is still found in the child class, just not accessible) protected: accessible within the class definition or within the definition of child classes

5. Fall 2010CSCI 383 Lecture 15 M. van Bommel 5 Inheritance: Extension and Contraction Because the behavior of a child class is strictly larger than the behavior of the parent, the child is an extension of the parent (larger) Because the child can override behavior to make it fit a specialized situation, the child is a contraction of the parent (smaller) This interplay between inheritance and overriding, extension and contraction, is what allows object- oriented systems to take very general tools and specialize them for specific projects. This interplay is ultimately the source of a great deal of the power of OOP

6. Fall 2010CSCI 383 Lecture 15 M. van Bommel 6 The is-a Rule Our idealization of inheritance is captured in a simple rule-of-thumb Try forming the English sentences “An A is-a B”. If it “sounds right” to your ear, then A can be made a subclass of B A dog is-a mammal, and therefore a dog inherits from mammal A car is-a engine sounds wrong, and therefore inheritance is not natural but a car has-a engine

7. Fall 2010CSCI 383 Lecture 15 M. van Bommel 7 Reuse of Code, Reuse of Concept Why do we use inheritance? Basically there are two major motivations: Reuse of code. Methods defined in the parent can be made available to the child without rewriting. Makes it easy to create new abstractions Reuse of concept. Methods described in the parent can be redefined and overridden in the child. Although no code is shared between parent and child, the concept embodied in the definition is shared

8. Fall 2010CSCI 383 Lecture 15 M. van Bommel 8 Syntax for Inheritance Languages use a variety of different syntax to indicate inheritance class Wall : public GraphicalObject -- C++ class Wall : GraphicalObject -- C# class Wall extends GraphicalObject -- Java (defclass Wall (GraphicalObject)()) -- CLOS type Wall = object (GraphicalObject) -- Object Pascal class Wall < GraphicalObject -- Ruby

9. Fall 2010CSCI 383 Lecture 15 M. van Bommel 9 Trees vs Forests There are two common views of class hierarchies: All classes are part of a single large class hierarchy. Thus, there is one class that is the original ancestor of all other classes. Smalltalk, Java and Delphi Pascal do this Classes are only placed in hierarchies if they have a relationship Results in a forest of many small hierarchies, but no single ancestor. C++, Objective-C, and Apple Object Pascal do this

10. Fall 2010CSCI 383 Lecture 15 M. van Bommel 10 Portion of the Little Smalltalk Hierarchy

11. Fall 2010CSCI 383 Lecture 15 M. van Bommel 11 An Argument for Substitution Consider the following argument: Instances of the subclass must possess all data areas associated with the parent class Instances of the subclass must implement all functionality defined for the parent class through inheritance at least (if not explicitly overridden) they can also define new functionality, but that is unimportant for the present argument Thus, an instance of a child class can mimic the behavior of the parent class. Thus it seems reasonable that a variable declared as a parent, should be able to hold a value generated from the child class

12. Fall 2010CSCI 383 Lecture 15 M. van Bommel 12 Principle of Substitution If we have two classes, A and B, such that class B is a subclass of class A, it should be possible to substitute instances of class B for instances of class A in any situation and with no observable effect Note: The principle of substitutability is sometimes called Liskov substitutability, since one of the first people to describe the idea was Barbara Liskov, of MIT.

13. Fall 2010CSCI 383 Lecture 15 M. van Bommel 13 Subclass vs Subtype The problem with this argument is that a child class can override a method and make arbitrary changes. It is therefore useful to define two separate concepts To say that A is a subclass of B merely asserts that A is formed using inheritance To say that A is a subtype of B asserts that A preserves the meaning of all the operations in B It is possible to form subclasses that are not subtypes; and (in some languages at least) form subtypes that are not subclasses

14. Fall 2010CSCI 383 Lecture 15 M. van Bommel 14 The two “subs” A class A is a subtype of a class B if the principle of substitution holds for the relationship between the classes A class A is a subclass of a class B is the substitution principle may or may not hold for the relationship between the classes

15. Fall 2010CSCI 383 Lecture 15 M. van Bommel 15 Interfaces and Abstract Classes An interface is similar to a class, but does not provide any implementation. A child class must override all methods. A middle ground is an abstract class. Here some methods are defined, and some (abstract methods) are undefined. A child class must fill in the definition for abstract methods An interface is like an abstract class in which all methods are abstract. In C++ an abstract method is called a pure virtual method abstract class Window {... abstract public void paint(); // child class must redefine... }

16. Fall 2010CSCI 383 Lecture 15 M. van Bommel 16 Forms of Inheritance Many types of inheritance are given their own special names. We will describe some of these specialized forms of inheritance Specialization Specification Construction Generalization or Extension Limitation Variance

17. Fall 2010CSCI 383 Lecture 15 M. van Bommel 17 Specialization Inheritance By far the most common form of inheritance is for specialization Each child class overrides a method inherited from the parent in order to specialize the class in some way

18. Fall 2010CSCI 383 Lecture 15 M. van Bommel 18 Specification Inheritance If the parent class is abstract, we often say that it is providing a specification for the child class, and therefore it is specification inheritance (a variety of specialization inheritance)

19. Fall 2010CSCI 383 Lecture 15 M. van Bommel 19 Inheritance for Construction If the parent class is used as a source for behavior, but the child class has no is-a relationship to the parent, then we say the child class is using inheritance for construction An example might be subclassing the idea of a Set from an existing List class Generally not a good idea, since it can break the principle of substitutability, but nevertheless sometimes found in practice

20. Fall 2010CSCI 383 Lecture 15 M. van Bommel 20 Inheritance for Generalization/ Extension If a child class generalizes or extends the parent class by providing more functionality, but does not override any method, we call it inheritance for generalization The child class doesn't change anything inherited from the parent, it simply adds new features

21. Fall 2010CSCI 383 Lecture 15 M. van Bommel 21 Inheritance for Limitation If a child class overrides a method inherited from the parent in a way that makes it unusable (for example, issues an error message), then we call it inheritance for limitation

22. Fall 2010CSCI 383 Lecture 15 M. van Bommel 22 Inheritance for Variance Two or more classes that seem to be related, but it is not clear who should be the parent and who should be the child Example: Mouse and TouchPad and JoyStick Better solution, abstract out common parts to new parent class, and use subclassing for specialization

23. Fall 2010CSCI 383 Lecture 15 M. van Bommel 23 Benefits of Inheritance Software Reuse Code Sharing Improved Reliability Consistency of Interface Rapid Prototyping Information Hiding

24. Fall 2010CSCI 383 Lecture 15 M. van Bommel 24 Cost of Inheritance Execution speed Program size Message Passing Overhead Program Complexity This does not mean you should not use inheritance, but rather than you must understand the benefits, and weigh the benefits against the costs