Extending a Class

Suppose we want to implement the game of Cram, which is identical to Domineering except that a player can play each domino either horizontally or vertically. We could write a new program that looks very similar to the old one. A better solution is to use inheritance. We write a new class Cram which extends Domineering (Figure 3-1). This new class specifies only the things that are different.

Cram is called a subclass of Domineering. Conversely, Domineering is a superclass of Cram. The relationship between the two classes is shown in Figure 3-2.

Figure 3-1. With inheritance, the Cram class is surprisingly short. Line 24 is necessary to clear out the input line after reading the column number. The method charAt(), invoked on the String INPUT.nextLine(), returns the character at a particular index.

Figure 3-2. UML class diagram showing that Cram is a subclass of Domineering. The arrow for class extension uses the same hollow head as the one for interface implementation, but has a solid instead of a dashed line.

The fields and methods not listed in the code for the Cram class are inherited from the Domineering class. If we invoke a method like playAt() or hasLegalMoveFor() on an instance of Cram, the method from the Domineering class is used. Inherited fields and methods make a Cram instance similar to a Domineering instance.

We can provide additional fields and methods, although the Cram class does not do so. The Cram class does override two methods, play() and main(). When we invoke the play() method on an instance of Cram, the new version is used. Additional fields and methods, along with overridden methods, make a Cram instance different from a Domineering instance.

The difference between overloading and overriding is a subtle one. When we overload a method name, Java decides which version to use based on the arguments which are passed to the method. When we override a method, Java decides which version to use based on the object on which the method is invoked. If two methods with the same name are in the same class but have different signatures, the method name is overloaded. If two methods with the same name and signature are in different classes (one a subclass of the other), the method in the subclass overrides the one in the superclass.

The invocation

super();

on line 6 in the constructor says, "Do whatever you would do to set up an instance of Domineering." A constructor in a subclass must always begin by invoking a constructor from the class it extends, although, as we will see later in this chapter, this invocation can often be implicit. In this case, the constructor from Domineering initializes the field that holds the board. Notice that it doesn't matter if we've forgotten how that field was initialized or even what it was called. Inheritance allows us to extend an encapsulated class without thinking about its inner workings. This allows us to develop correct software much more rapidly.

Extending a class is similar to implementing an interface. The key difference is that a superclass provides functionality, while an interface merely makes promises. A class can implement many interfaces, but it can only have one superclass. If a subclass had two superclasses, there would be problems if both of them provided some method which the subclass did notit would not be clear which version should be inherited.

Polymorphism and Inheritance

As a second example of inheritance, consider the class Light (Figure 3-3). This very simple class has only one field: a boolean indicating whether it is on or off. The toString() method returns the String "O" if the Light is on and "." if it is off.

Figure 3-3. The class Light models a light bulb.

The Light class is extended by the ColoredLight class (Figure 3-4), which also has a char indicating its color. The color is determined randomly in the constructor. A ColoredLight looks the same as a Light when it is off, but toString() returns "R", "G", or "B", respectively, for red, green, or blue ColoredLights.

Figure 3-4. ColoredLight is a subclass of Light.

ColoredLight inherits the field on and adds a new field color. It inherits the methods isOn() and setOn(). It overrides the toString() method and adds a new method, getColor(). This is illustrated in Figure 3-5.

Figure 3-5. UML class diagram showing that ColoredLight extends Light. Only new fields and methods are shown in the subclass. Inherited or overridden fields can be read from the superclass.

(This item is displayed on page 72 in the print version)

Although ColoredLight inherits the field on, it does not have direct access to the field. On line 29, the toString() method must work through the inherited method isOn() because the field on is private in Light. The private status of this field means that no other class, not even a subclass of Light, has direct access to on. This is information hiding enforcing encapsulation.

A variable of type Light can hold an instance of Light or of any subclass of Light. It is therefore a polymorphic type. Thus, it is perfectly legal to say:

Light bulb = new ColoredLight();

Why not simply cut to the chase and declare bulb to be of type Object? By declaring it to be of type Light, we guarantee that all of the methods defined in the Light class are available. Every method in Light has to be either inherited or overridden, so it is safe to call such a method on bulb. We can turn bulb off without knowing its exact class:

bulb.setOn(false);

If bulb were of type Object, we would have to cast it in order to do this.

If we invoke toString() on bulb, Java uses the class of the instance (ColoredLight) instead of the type of the variable (Light) to determine which version of the method to use. This process is called dynamic dispatch, because the decision is made dynamically at run time rather than once and for all at compile time.

Chains of Inheritance

Can we make a subclass of a subclass? Sure! The class FlashingColoredLight (Figure 3-6) extends ColoredLight. It turns itself on or off every time toString() is invoked. (This is slightly bad style, because we normally don't expect toString() to change an object's state.)

Figure 3-6. FlashingColoredLight extends ColoredLight.

Inheritance is transitive, so FlashingColoredLight inherits every field and method from Light except for those methods overridden by ColoredLight.

The relationship between the three classes is shown in Figure 3-7. We can say that ColoredLight and FlashingColoredLight are proper descendants of Light. Strictly speaking, the descendants of Light are itself plus its proper descendants. This is consistent with the concepts of subset and proper subset from set theory. Conversely, Light and ColoredLight are proper ancestors of FlashingColoredLight. All three classes are ancestors of FlashingColoredLight.

Figure 3-7. A chain of inheritance.

(This item is displayed on page 74 in the print version)

Alternately, we can say that ColoredLight and FlashingColoredLight are both subclasses of Light, but only ColoredLight is a direct subclass. Conversely, both Light and ColoredLight are superclasses of FlashingColoredLight, but ColoredLight is the direct superclass.

We will omit the words "proper" and "direct" when there is no danger of confusion.

Is-a vs Has-a

It takes some experience to know when to extend a class. For example, suppose we want to model a string of Christmas lights. Should we extend the Light class?

To resolve this question, we should think about the relation between the new class and the one we're considering extending. If an instance of the new class is just like an instance of the old class, with a few modifications, we should extend. If an instance of the new class merely has an instance of the old class as a component, we should not. For example, a ColoredLight is a Light, but with the added feature of color, so extension is appropriate. On the other hand, an instance of BeetleGame merely has two beetles, so it is not appropriate for it to extend Beetle. Object-oriented programmers refer to these as is-a and has-a relationships.

A string of Christmas lights has several lights, so it should not extend Light. Instead, it should contain an array of Lights in a field. The LightString class is shown in Figure 3-8.

Figure 3-8. A LightString contains some Lights, but it is not a special kind of Light, so extension is not appropriate. The enhanced for loop used in lines 2123 and 2830 is explained in Appendix A.

Even though the LightString class has a method isOn(), it does not make sense to say this method overrides the one in Light, because LightString is not a subclass of Light.

The LightString class uses polymorphism to store both Lights and ColoredLights in the same array. The constructor uses the % operator to put Lights in even-numbered positions and ColoredLights in odd-numbered ones. (The first index is 0, which is even.) The keyword new is used both to allocate the array bulb and to create each individual object within that array.

When we run the LightString class, the output looks like this (colors will vary on each run):

.................... OROBOGOGOGOGOBOGOROR

The relationship between all four of the Light-related classes is shown in Figure 3-9.

Figure 3-9. A LightString contains 0 or more Lights, some of which may actually be ColoredLights or FlashingColoredLights.

(This item is displayed on page 76 in the print version)

Beginning object-oriented programmers often overuse inheritance. Inheritance should be used only when an instance of the subclass can stand in for an instance of the superclass. For example, suppose we have a class Bicycle with a method pedal(). We should not define Motorcycle to extend Bicycle, because the pedal() method wouldn't make sense for a Motorcycle. Since Bicycle is a polymorphic type, any method that accepts a Bicycle might receive an instance of a subclass of Bicycle instead. To prevent such code from breaking, an instance of any subclass should work in place of a regular Bicycle. We might reasonably extend Bicycle with ElectricBicycle (the kind that can be pedaled or powered with an electric motor), but not with Motorcycle.

Exercises