User Tools

Site Tools


Chapter 8: Inheritance

This chapter reviews inheritance topics first covered in CSci 157. Since we've reviewed the basics, let's focus on the concepts of abstract classes and abstract methods, class hierarchies, uses of (and alternatives to) inheritance, and interfaces.

The chapter illustrates both inheritance and interfaces through an extended example of a graphics library that provides similar functionality to Objectdraw. If you've ever wanted to know how something like Objectdraw is implemented, this example gives you a chance to look under the hood. However, this isn't a graphics course, so we won't spend any class time on the graphics library other than as an example of class hierarchy.


parameterized class types - Curiously, inheritance can be used to create types in parameterized classes such as ArrayList<String>. This appears to be a way to create a type alias, which is just a shorter name for an existing type. For example:

public class StringMap extends TreeMap<String, String> {
 // EMPTY! 

This only exists to let us use the shorter name StringMap which really is a new class, but is otherwise used the exact same way the TreeMap would be.

class hierarchy - a visualization of the inheritance relationship. The base class is at the top of the hierarchy and its derived classes are shown connected to it by triangular arrows. There may be several levels of classes in the heirarchy. Some integrated development environments (such as BlueJ) will visualize this automatically. The text shows examples of UML diagrams which are another way to visualize the design of the hierarchy.

In this example, the class Employee is the base class:

There is a larger example in Figure 8-7.

abstract classes - The Employee class in the above example is also an abstract class. This type of class defines a minimal core set of instance variables and methods for its subclasses to inherit and use, but no objects of the type are ever created.

Another abstract class is the GObject class of Figure 8-13.

abstract methods - While an abstract class may define a default implementation of its constructor and methods, it is not required to. Any method which does not have an implementation is labeled abstract, and consists only of its method signature. Derived classes are expected to override these methods.

  // in class Employee
  public abstract double getPay();

composition - an alternative to inheritance; rather than inherit from a class, include an object of that class type as an instance variable. We already do this quite a bit, this just adds some justification.

I once considered the idea that since the class that implements the Simple0 processor from Project 1 is based on a stack, it should just be derived from the Stack class, thinking that maybe the processor IS-A stack. Or is it? The processor actually has several component parts: the stack, the condition codes, possibly even the list of instructions. So it makes sense to say the processor HAS-A stack, and therefore should use composition instead. Using the terminology of the textbook, when an instruction tells the processor to push a value on the stack, we forward that request to the Stack object's push method, simply by calling it.

interfaces - Another alternative to inheritance; we can define an interface which defines a minimal set of methods that a class implementing it will define. We'll see a number of examples as we go. An example in this chatper is the GFillable interface in Figure 8-16.

cs257/roberts_chapter_8.txt · Last modified: 2021/03/13 00:30 by scarl