Designing with inheritance

Once

you learn about polymorphism, it can seem that everything ought to be inherited

because polymorphism is such a clever tool. This can burden your designs; in

fact if you choose inheritance first when you’re using an existing class

to make a new class things can become needlessly complicated.

A

better approach is to choose

//: Transmogrify.java
// Dynamically changing the behavior of
// an object via composition.
 
interface Actor {
  void act();
}
 
class HappyActor implements Actor {
  public void act() {
    System.out.println("HappyActor");
  }
}
 
class SadActor implements Actor {
  public void act() {
    System.out.println("SadActor");
  }
}
 
class Stage {
  Actor a = new HappyActor();
  void change() { a = new SadActor(); }
  void go() { a.act(); }
}
 
public class Transmogrify {
  public static void main(String[] args) {
    Stage s = new Stage();
    s.go(); // Prints "HappyActor"
    s.change();
    s.go(); // Prints "SadActor"
  }
} ///:~ 

A

object contains a handle to an

,

which is initialized to a

object. This means

produces a particular behavior. But since a handle can be re-bound to a

different object at run time, a handle for a

object can be substituted in

and then the behavior produced by

changes. Thus you gain dynamic flexibility at run time. In contrast, you

can’t decide to inherit differently at run time; that must be completely

determined at compile time.

A

general guideline is “Use inheritance to express differences in behavior,

and member variables to express variations in state.” In the above

example, both are used: two different classes are inherited to express the

difference in the

method, and

uses composition to allow its state to be changed. In this case, that change in

state happens to produce a change in behavior.

Pure
inheritance vs. extension

When

studying inheritance, it would seem that the cleanest way to create an

inheritance hierarchy is to take the “pure” approach. That is, only

methods that have been established in the base class or

are to be overridden in the derived class, as seen in this diagram:

This

can be termed a pure “

This

can be thought of as

That

is, the base class can receive any message you can send to the derived class

because the two have exactly the same interface. All you need to do is upcast

from the derived class and never look back to see what exact type of object

you’re dealing with. Everything is handled through polymorphism.

When

you see it this way, it seems like a pure “is-a” relationship is

the only sensible way to do things, and any other

While

this is also a useful and sensible approach (depending on the situation) it has

a drawback. The extended part of the interface in the derived class is not

available from the base class, so once you upcast you can’t call the new

methods:

If

you’re not upcasting in this case, it won’t bother you, but often

you’ll get into a situation in which you need to rediscover the exact

type of the object so you can access the extended methods of that type. The

following sections show how this is done.

Downcasting
and run-time

type
identification

Since

you lose the specific type information via an

(moving up the inheritance hierarchy), it makes sense that to retrieve the type

information – that is, to move back down the inheritance hierarchy

– you use a

To

solve this problem there must be some way to guarantee that a downcast is

correct, so you won’t accidentally cast to the wrong type and then send a

message that the object can’t accept. This would be quite unsafe.

In

some languages (like C++) you must perform a special operation in order to get

a type-safe downcast, but in Java

is checked! So even though it looks like you’re just performing an

ordinary parenthesized cast, at run time this cast is checked to ensure that it

is in fact the type you think it is. If it isn’t, you get a

.

This act of checking types at run time is called

//: RTTI.java
// Downcasting & Run-Time Type
// Identification (RTTI)
import java.util.*;
 
class Useful {
  public void f() {}
  public void g() {}
}
 
class MoreUseful extends Useful {
  public void f() {}
  public void g() {}
  public void u() {}
  public void v() {}
  public void w() {}
}
 
public class RTTI {
  public static void main(String[] args) {
    Useful[] x = {
      new Useful(),
      new MoreUseful()
    };
    x[0].f();
    x[1].g();
    // Compile-time: method not found in Useful:
    //! x[1].u();
    ((MoreUseful)x[1]).u(); // Downcast/RTTI
    ((MoreUseful)x[0]).u(); // Exception thrown
  }
} ///:~ 

As

in the diagram,

extends the interface of

.

But since it’s inherited, it can also be upcast to a

.

You can see this happening in the initialization of the array

in

.

Since both objects in the array are of class

,

you can send the

and

methods to both, and if you try to call

(which exists only in

)

you’ll get a compile-time error message.

If

you want to access the extended interface of a

object, you can try to downcast. If it’s the correct type, it will be

successful. Otherwise, you’ll get a

There’s

more to RTTI than a simple cast. For example, there’s a way to see what

type you’re dealing with

you try to downcast it. All of Chapter 11 is devoted to the study of different

aspects of Java run-time type identification.

|

|