COMP 110/401 Prasun Dewan1 17. Inheritance Inheritance in an object‐oriented language is not much different than inheritance in the real world. Just it is possible to automatically inherit money from a benefactor or genes from ancestors, it is possible to inherit code from an object type – specifically the methods and variables defined by that type. The idea of inheritance is related to the IS‐A relation. Again, this relation is used in the non computer world. A human is a mammal; a salmon is a fish; and each of you is a student. Similarly, we say that ACartesianPointy is a Point because it implements Point. We will see that inheritance, like interface implementation, is also an is‐a relation. We will show how type checking of object variables is based on this relation. In this chapter, we will mainly use collections to illustrate and motivate inheritance and the is‐a relation. We have seen how we can create certain kinds of sequences, such as histories and databses, using arrays. Some of these types can be considered as special cases of other types. We will see how a specialized type can inherit the code from a more general type much as a child inherits genes from a parent. Inheritance We have seen two kinds of collections created using arrays, a history and a database. A history is defined by the interface, StringHistory and implemented by the class, AStringHistory; while a database is defined by the interface, StringDatabase, and implemented by the class AStringDatabase. Figure 5 shows the members (methods and instance variables) declared in the interfaces and classes. Let us compare the database class and interfaces with the history class and interface. The database interface defines all the methods of the history interface, plus some more. In other words, logically, it is an “extension’’ of the history interface, containing copies of the methods elementAt, addElement, and size, and adding the methods, deleteElement, and clear. Similarly, logically, the database class is an extension of the history class, in that it contains a copy of all of the members defined in the latter – the size and contents instance variables, and the addElement, size, and elementAt instance methods. As a result, AStringDatabase implements a superset of the functionality of AStringHistory. However, physically, the database interface and class are not extensions of the 1  Copyright Prasun Dewan, 2009.history interface and class, because they duplicate code in the latter – each member of the history interface/class is re‐declared in the database interface/class. In fact, Java allows us to create logical interface and class extensions as also physical extensions. The database interface can share the declarations of the history interface as shown here: public interface StringDatabase extends StringHistory { public void deleteElement(String element); public void clear(); public boolean member(String element); } The keyword extends tells Java that the interface StringDatabase is a physical extension of StringHistory, which implies that it implicitly includes or inherits the constants and methods declared in the latter. As a result, only the additional declarations must be explicitly included in the definition of this interface. Below, we see how the database class can share the code of the history class: public class AStringDatabase extends AStringHistory implements StringDatabase { public void deleteElement(String element) { … } int indexOf(String element) { … } void shiftUp(int startIndex) { … } public boolean member(String element) { … } public void clear() { … } } The method bodies are not given here since they are the same as we saw earlier. The important thing to note here is that the class does not contain copies of the methods and instance variables declared in AStringHistory because it now (physically) extends it.Given an interface or class, A, and an extension, B, of it, we will refer to A as a base or supertype of B; and to B as a derivation, subtype, or simply extension of A (Figure 6). Any class that implements an extension of an interface must implement all the methods declared in both the extended interface and the extension. Thus, in our example, AStringDatabase must implement not only the methods declared in StringDatabase, the interface it implements, but also the ones declared in the interface, StringHistory, the interface extended by StringDatabase. Figure 1. Logical but not physical extensions Figure 2. Physical and logical extensionsThus, the new definition of StringDatabase and AStringDatabase are equivalent to the ones given before. Why Inheritance There are several reasons for extending interfaces and classes, as we have done above, rather than creating new ones from scratch, as we did before: • Reduced Programming/Storage Costs: The most obvious reason is that we do not have to write and store on the computer a copy of the code in the base type, thereby reducing programming and storage costs. The programming cost, of course, is minimal if we had a convenient facility to cut and paste. However, the source code of the base type may not always be available, which does not prevent it from being sub typed. • Easier Evolution: Code tends to change. We may decide to change the MAX_SIZE constant of AStringHistory, in which case, would have to find and change all other classes that are logical but not physical extensions. • Polymorphism: Inheritance allows us to support new kinds of polymorphism, as explained below. • Modularity & Reusability: We assume above that the base class and interface already existed when we created subclasses of them. For instance, we assumed first that we needed string histories and created appropriate interfaces and classes to support them. Later, when we found the need for string databases, we simply extended existing software. What if we have not had the need for string histories, and were told to create string histories from scratch? Even in this case, we may want to first create string histories and then extend them rather than create unextended string databases, because the extension approach increases modularity, thereby giving the accompanying advantages. In this example, it makes us understand, code, and prove correct the two interfaces and classes separately. Moreover, if we later end up needing string histories, we have the interface and class for instantiating them. The approach