In the real world, you often categorize concepts into hierarchies. Hierarchies are frequently represented as trees, with the most general concepts at the root of the hierarchy and more specialized ones towards the branches. Figure 1 shows a typical example.

In Java it is equally common to group classes in inheritance hierarchies. The classes representing the most general concepts are near the root, more specialized classes towards the branches. For example, Figure 2 shows part of the hierarchy of Swing user-interface components in Java.

We must introduce some more terminology for expressing the relationship between the classes in an inheritance hierarchy. The more general class is called the superclass. The more specialized class that inherits from the superclass is called the subclass. In our example, JPanel is a subclass of JComponent.

Figure 2 uses the UML notation for inheritance. In a class diagram, you denote inheritance by a solid arrow with a "hollow triangle" tip that points to the super-class.

When designing a hierarchy of classes, you ask yourself which features and behaviors are common to all the classes that you are designing. Those common properties are placed in a superclass. For example, all user-interface components have a width and height, and the getWidth and getHeight methods of the JComponent class return the component's dimensions. More specialized properties can be found in subclasses. For example, buttons can have text and icon labels. The class Abstract-Button, but not the superclass JComponent, has methods to set and get the button text and icon, and instance variables to store them. The individual button classes (such as JButton, JRadioButton, and JCheckBox) inherit these properties. In fact, the Abstract-Button class was created to express the commonality among these buttons.

Figure 10.1. A Hierarchy of Vehicle Types

Figure 10.2. A Part of the Hierarchy of Swing User-Interface Components

Figure 10.3. Inheritance Hierarchy for Bank Account Classes

We will use a simpler example of a hierarchy in our study of inheritance concepts. Consider a bank that offers its customers the following account types:

Figure 3 shows the inheritance hierarchy. Exercise P10.2 asks you to add another class to this hierarchy.

Next, let us determine the behavior of these classes. All bank accounts support the getBalance method, which simply reports the current balance. They also support the deposit and withdraw methods, although the details of the implementation differ. For example, a checking account must keep track of the number of transactions to account for the transaction fees.

The checking account needs a method deductFees to deduct the monthly fees and to reset the transaction counter. The deposit and withdraw methods must be overridden to count the transactions.

The savings account needs a method addInterest to add interest.

To summarize: The subclasses support all methods from the superclass, but their implementations may be modified to match the specialized purposes of the subclasses. In addition, subclasses are free to introduce additional methods.

2. Why don't we place the addInterest method in the BankAccount class?

In this section, we begin building the inheritance hierarchy of bank account classes. You will learn how to form a subclass from a given superclass. Let's start with the SavingsAccount class. Here is the syntax for the class declaration:

public class SavingsAccount extends BankAccount
{
   added instance variables
   new methods
}

In the SavingsAccount class declaration you specify only new methods and instance variables. The SavingsAccount class automatically inheritsthe methods of the BankAc-count class. For example, the deposit method automatically applies to savings accounts:

SavingsAccount collegeFund = new SavingsAccount(10);
   // Savings account with 10% interest
collegeFund.deposit(500);
   // OK to use BankAccount method with SavingsAccount object

Let's see how savings account objects are different from BankAccount objects. We will set an interest rate in the constructor, and we need a method to apply that interest periodically. That is, in addition to the three methods that can be applied to every account, there is an additional method addInterest. The new method and instance variable must be declared in the subclass.

public class SavingsAccount extends BankAccount
{
   private double interestRate;

   public SavingsAccount(double rate)
   {
      Constructor implementation
   }

   public void addInterest()
   {
      Method implementation
   }
}

A subclass object automatically has the instance variables declared in the superclass. For example, a SavingsAccount object has an instance variable balance that was declared in the BankAccount class.

Any new instance variables that you declare in the subclass are present only in subclass objects. For example, every SavingsAccount object has an instance variable interestRate. Figure 4 shows the layout of a SavingsAccount object.

Figure 10.4. Layout of a Subclass Object

Inheritance

Next, you need to implement the new addInterest method. The method computes the interest due on the current balance and deposits that interest to the account.

public class SavingsAccount extends BankAccount
{
   private double interestRate;

   public SavingsAccount(double rate)
   {
      interestRate = rate;
   }

   public void addInterest()
   {
      double interest = getBalance() * interestRate / 100;
      deposit(interest);
   }
}

The addInterest method calls the getBalance and deposit methods rather than directly updating the balance variable of the superclass. This is a consequence of encapsulation. The balance variable was declared as private in the BankAccount class. The addInterest method is declared in the SavingsAccount class. It does not have the right to access a private instance variable of another class.

Note how the addInterest method calls the inherited getBalance and deposit methods without specifying an implicit parameter. This means that the calls apply to the implicit parameter of the addInterest method.

In other words, the statements in the addInterest method are a shorthand for the following statements:

double interest = this.getBalance() * this.interestRate / 100;
this.deposit(interest);

This completes the implementation of the SavingsAccount class. You will find the complete source code below.

You may wonder at this point in what way inheritance differs from implementing an interface. An interface is not a class. It has no behavior. It merely tells you which methods you should implement. A superclass has behavior that the subclasses inherit.

ch10/accounts/SavingsAccount.java

1 /**
2    An account that earns interest at a fixed rate.
3 */
4 public class SavingsAccount extends BankAccount
5 {
6    private double interestRate;
7
8    /**
9       Constructs a bank account with a given interest rate.
10       @param rate the interest rate
11    */
12    public SavingsAccount(double rate)
13    {
14       interestRate = rate;
15    }
16
17    /**
18       Adds the earned interest to the account balance.
19    */
20    public void addInterest()
21    {
22       double interest = getBalance() * interestRate / 100;
23       deposit(interest);
24    }
25 }

4. Name four methods that you can apply to SavingsAccount objects.

5. If the class Manager extends the class Employee, which class is the superclass and which is the subclass?

Shadowing Instance Variables

A subclass has no access to the private instance variables of the superclass. For example, the methods of the SavingsAccount class cannot access the balance instance variable:

public class SavingsAccount extends BankAccount
{
   public void addInterest()
   {
      double interest = getBalance() * interestRate / 100;
      balance = balance + interest; // Error
   }
   ...
}

It is a common beginner's error to "solve" this problem by adding another instance variable with the same name.

public class SavingsAccount extends BankAccount
{
   private double balance; // Don't
   ...
   public void addInterest()
   {
      double interest = getBalance() * interestRate / 100;
      balance = balance + interest; // Compiles but doesn't update the correct balance
   }
}

Sure, now the addInterest method compiles, but it doesn't update the correct balance! Such a SavingsAccount object has two instance variables, both named balance (see Figure 5). The getBalance method of the superclass retrieves one of them, and the addInterest method of the subclass updates the other.

Figure 10.5. Shadowing Instance Variables

A subclass method overrides a superclass method if it has the same name and parameter types as a superclass method. When such a method is applied to a subclass object, the overriding method, and not the original method, is executed.

We turn to the CheckingAccount class for an example of overriding methods. Recall that the BankAccount class has three methods:

public class BankAccount
{
   ...
   public void deposit(double amount) { ... }
   public void withdraw(double amount) { ... }
   public double getBalance() { ... }
}

The CheckingAccount class declares these methods:

public class CheckingAccount extends BankAccount
{
  . . .
  public void deposit(double amount) { . . . }
  public void withdraw(double amount) { . . . }
  public void deductFees() { . . . }
}

The deposit and withdraw methods of the CheckingAccount class override the deposit and withdraw methods of the BankAccount class to handle transaction fees. However, the deductFees method does not override another method, and the getBalance method is not overridden.

Let's implement the deposit method of the CheckingAccount class. It increments the transaction count and deposits the money:

public class CheckingAccount extends BankAccount
{
   ...
   public void deposit(double amount)
   {
      transactionCount++;
      // Now add amount to  balance
      ...
   }
}

Now we have a problem. We can't simply add amount to balance:

public class CheckingAccount extends BankAccount
{
   ...
   public void deposit(double amount)
   {
      transactionCount++;
      // Now add amount to  balance
      balance = balance + amount; // Error
   }
}

Although every CheckingAccount object has a balance instance variable, that instance variable is private to the superclass BankAccount. Subclass methods have no more access rights to the private data of the superclass than any other methods. If you want to modify a private superclass instance variable, you must use a public method of the superclass.

Calling a Superclass Method

How can we add the deposit amount to the balance, using the public interface of the BankAccount class? There is a perfectly good method for that purpose—namely, the deposit method of the BankAccount class. So we must invoke the deposit method on some object. On which object? The checking account into which the money is deposited—that is, the implicit parameter of the deposit method of the Checking-Account class. To invoke another method on the implicit parameter, you don't specify the parameter but simply write the method name, like this:

public class CheckingAccount extends BankAccount
{
   public void deposit(double amount)
   {
      transactionCount++;
      // Now add amount to  balance
      deposit(amount); // Not complete
   }
   ...
}

But this won't quite work. The compiler interprets

deposit(amount);

as

this.deposit(amount);

The this parameter is of type CheckingAccount. There is a method called deposit in the CheckingAccount class. Therefore, that method will be called—but that is just the method we are currently writing! The method will call itself over and over, and the program will die in an infinite recursion (discussed in Chapter 13).

Instead, we must be specific that we want to invoke only the superclass's deposit method. There is a special reserved word super for this purpose:

public class CheckingAccount extends BankAccount
{
   public void deposit(double amount)
   {

transactionCount++;
      // Now add amount to balance
      super.deposit(amount);
   }
   ...
}

This version of the deposit method is correct. To deposit money into a checking account, update the transaction count and call the deposit method of the superclass.

The remaining methods of the CheckingAccount class also invoke a superclass method.

public class CheckingAccount extends BankAccount
{
   private static final int FREE_TRANSACTIONS = 3;
   private static final double TRANSACTION_FEE = 2.0;

   private int transactionCount;
    ...
   public void withdraw(double amount)
   {
      transactionCount++;
      // Now subtract amount from balance
      super.withdraw(amount);
   }

   public void deductFees()
   {
      if (transactionCount > FREE_TRANSACTIONS)
      {
         double fees = TRANSACTION_FEE * (transactionCount - FREE_TRANSACTIONS);
         super.withdraw(fees);
      }
       transactionCount = 0;
   }
   ...
}

7. Why does the withdraw method of the CheckingAccount class call super.withdraw?

8. Why does the deductFees method set the transaction count to zero?

void println(int x)

void println(String x)

public class CheckingAccount extends BankAccount
{
   ...
   public void deposit(int amount) // Error: should be double
   {
      ...
   }
}

public void withdraw(double amount)
{
   transactionCount++;
   withdraw(amount);
   // Error—should be super.withdraw(amount)
}

In this section, we discuss the implementation of constructors in subclasses. As an example, let's declare a constructor to set the initial balance of a checking account.

We want to invoke the BankAccount constructor to set the balance to the initial balance. There is a special instruction to call the superclass constructor from a subclass constructor. You use the reserved word super, followed by the construction parameters in parentheses:

public class CheckingAccount extends BankAccount
{
   public CheckingAccount(double initialBalance)
   {
      //  Construct superclass
       super(initialBalance);
      // Initialize transaction count
      transactionCount = 0;
   }
   ...
}

When the reserved word super is immediately followed by a parenthesis, it indicates a call to the superclass constructor. When used in this way, the constructor call must be the first statement of the subclass constructor. If super is followed by a period and a method name, on the other hand, it indicates a call to a superclass method, as you saw in the preceding section. Such a call can be made anywhere in any subclass method.

The dual use of the super reserved word is analogous to the dual use of the this reserved word (see Special Topic 3.1).

If a subclass constructor does not call the superclass constructor, the superclass must have a constructor without parameters. That constructor is used to initialize the superclass data. However, if all constructors of the superclass require parameters, then the compiler reports an error.

For example, you can implement the CheckingAccount constructor without calling the superclass constructor. Then the BankAccount class is constructed with its BankAc-count() constructor, which sets the balance to zero. Of course, then the CheckingAc-count constructor must explicitly deposit the initial balance.

Most commonly, however, subclass constructors have some parameters that they pass on to the superclass and others that they use to initialize subclass instance variables.

Calling a Superclass Constructor

ch10/accounts/CheckingAccount.java

1 /**
2    A checking account that charges transaction fees.
3 */
4 public class CheckingAccount extends BankAccount
5 {
6    private static final int FREE_TRANSACTIONS = 3;
7    private static final double TRANSACTION_FEE = 2.0;
8
9    private int transactionCount;
10
11    /**
12       Constructs a checking account with a given balance.
13       @param initialBalance the initial balance
14    */
15    public CheckingAccount(double initialBalance)
16    {
17       // Construct superclass
18        super(initialBalance);
19
20       // Initialize transaction count
21        transactionCount = 0;
22    }
23
24    public void deposit(double amount)
25    {
26        transactionCount++;
27       // Now add amount to balance
28       super.deposit(amount);
29    }
30
31    public void withdraw(double amount)
32    {
33        transactionCount++;
34       // Now subtract amount from balance
35        super.withdraw(amount);
36    }
37
38    /**
39       Deducts the accumulated fees and resets the
40       transaction count.
41    */
42    public void deductFees()
43    {
44       if (transactionCount > FREE_TRANSACTIONS)
45       {
46          double fees = TRANSACTION_FEE *
47                (transactionCount - FREE_TRANSACTIONS);
48          super.withdraw(fees);
49       }
50       transactionCount = 0;
51    }
52 }

10. When you invoke a superclass method with the super reserved word, does the call have to be the first statement of the subclass method?

It is often necessary to convert a subclass type to a superclass type. Occasionally, you need to carry out the conversion in the opposite direction. This section discusses the conversion rules.

The class SavingsAccount extends the class BankAccount. In other words, a Savings-Account object is a special case of a BankAccount object. Therefore, a reference to a SavingsAccount object can be converted to a BankAccount reference.

SavingsAccount collegeFund = new SavingsAccount(10);
BankAccount anAccount = collegeFund; // OK

Furthermore, all references can be converted to the type Object.

Object anObject = collegeFund; // OK

Now the three object references stored in collegeFund, anAccount, and anObject all refer to the same object of type SavingsAccount (see Figure 6).

However, the variables anAccount and anObject know less than the full story about the object references that they store. Because anAccount is a variable of type BankAc-count, you can invoke the deposit and withdraw methods. You cannot use the addInterest method, though—it is not a method of the BankAccount class:

anAccount.deposit(1000); // OK
anAccount.addInterest(); // No—not a method of the type of the anAccount variable

And, of course, the variable anObject knows even less. You can't even invoke the deposit method on it—deposit is not a method of the Object class.

Why would anyone want to know less about an object reference and use a variable whose type is a superclass? This can happen if you want to reuse code that knows about the superclass but not the subclass. Here is a typical example. Consider a transfer method that transfers money from one account to another:

public void transfer(double amount, BankAccount other)
{
   withdraw(amount);
   other.deposit(amount);
}

You can use this method to transfer money from one bank account to another:

BankAccount momsAccount = ... ;
BankAccount harrysAccount = ... ;
momsAccount.transfer(1000, harrysAccount);

Figure 10.6. Variables of Different Types Can Refer to the Same Object

You can also use the method to transfer money into a CheckingAccount:

CheckingAccount harrysChecking = ... ;
momsAccount.transfer(1000, harrysChecking);
   // OK to pass a CheckingAccount reference to a method expecting a BankAccount

The transfer method expects a reference to a BankAccount, and it gets a reference to a CheckingAccount object. That is perfectly legal. The transfer method doesn't actually know that, in this case, the parameter variable other contains a reference to a Check-ingAccount object. All it cares about is that the object can carry out the deposit method. This is assured because the other variable has the type BankAccount.

Very occasionally, you need to carry out the opposite conversion, from a super-class type to a subclass type. For example, you may have a variable of type Object, and you know that it actually holds a BankAccount reference. In that case, you can use a cast to convert the type:

BankAccount anAccount = (BankAccount) anObject;

However, this cast is somewhat dangerous. If you are wrong, and anObject actually refers to an object of an unrelated type, then an exception is thrown.

To protect against bad casts, you can use the instanceof operator. It tests whether an object belongs to a particular type. For example,

anObject instanceof BankAccount

returns true if the type of anObject is convertible to BankAccount. This happens if anObject refers to an actual BankAccount or a subclass such as SavingsAccount. Using the

if (anObject instanceof BankAccount)
{
   BankAccount anAccount = (BankAccount) anObject;
   ...
}

The instanceof Operator

12. Why can't we change the second parameter of the transfer method to the type Object?

In Java, the type of a variable does not determine the type of the object to which it refers. For example, a variable of type BankAccount can hold a reference to an actual BankAccount object or a subclass object such as SavingsAccount. You already encountered this phenomenon in Chapter 9 with variables whose type was an interface. A variable whose type is Measurable holds a reference to an object of a class that implements the Measurable interface, perhaps a Coin object or an object of an entirely different class.

What happens when you invoke a method on a variable of type BankAccount? For example,

BankAccount anAccount = new CheckingAccount();
anAccount.deposit(1000);

Which deposit method is called? The anAccount variable has type BankAccount, so it would appear as if BankAccount.deposit is called. On the other hand, the CheckingAccount class provides its own deposit method that updates the transaction count. The reference stored in the anAccount variable actually refers to an object of the subclass CheckingAccount, so it would be appropriate if the CheckingAccount.deposit method were called instead.

Java uses dynamic method lookup to determine which method to invoke. The method to be called is always determined by the type of the actual object, not the type of the variable. That is, if the actual object has the type CheckingAccount, then the CheckingAccount.deposit method is called. It does not matter that the object reference is stored in a variable of type BankAccount.

Have another look at the transfer method:

public void transfer(double amount, BankAccount other)
{
   withdraw(amount);
   other.deposit(amount);
}

Suppose you call

anAccount.transfer(1000, anotherAccount);

Two method calls are the result:

anAccount.withdraw(1000);
anotherAccount.deposit(1000);

Depending on the actual types of the objects whose references are stored in anAc-count and anotherAccount, different versions of the withdraw and deposit methods are called. This is an example of polymorphism. As we discussed in Chapter 9, polymorphism is the ability to treat objects with differences in behavior in a uniform way.

If you look into the implementation of the transfer method, it may not be immediately obvious that the first method call

withdraw(amount);

depends on the type of an object. However, that call is a shortcut for

this.withdraw(amount);

The this parameter holds a reference to the implicit parameter, which can refer to a BankAccount or a subclass object.

The following program calls the polymorphic withdraw and deposit methods. You should manually calculate what the program should print for each account balance, and confirm that the correct methods have in fact been called.

ch10/accounts/AccountTester.java

1 /**
2    This program tests the BankAccount class and
3    its subclasses.
4 */
5 public class AccountTester
6 {
7    public static void main(String[] args)
8    {
9       SavingsAccount momsSavings = new SavingsAccount(0.5);
10
11       CheckingAccount harrysChecking = new CheckingAccount(100);
12
13       momsSavings.deposit(10000);
14
15       momsSavings.transfer(2000, harrysChecking);
16       harrysChecking.withdraw(1500);
17       harrysChecking.withdraw(80);
18
19       momsSavings.transfer(1000, harrysChecking);
20       harrysChecking.withdraw(400);
21
22       // Simulate end of month
23       momsSavings.addInterest();
24       harrysChecking.deductFees();
25
26       System.out.println("Mom's savings balance: "
27             + momsSavings.getBalance());
28        System.out.println("Expected: 7035");
29
30       System.out.println("Harry's checking balance: "
31              + harrysChecking.getBalance());
32        System.out.println("Expected: 1116");
33    }
34 }

Program Run

Mom's savings balance: 7035.0
Expected: 7035
Harry's checking balance: 1116.0
Expected: 1116

14. If a refers to a checking account, what is the effect of calling a.transfer(1000, a)?

public class BankAccount
{
   public void deductFees() { ... }
   ...
}

public abstract void deductFees();

public abstract class BankAccount
{
   public abstract void deductFees();
   ...
}

BankAccount anAccount; // OK
anAccount = new BankAccount(); // Error--BankAccount is abstract

anAccount = new SavingsAccount(); // OK
anAccount = null; // OK

public final class String { ... }

public class SecureAccount extends BankAccount
{
   ...
   public final boolean checkPassword(String password)
   {
      ...
   }
}

public class BankAccount
{
   public void withdraw(double amount) { ... }
   ...
}

public class CheckingAccount extends BankAccount
{
   private void withdraw(double amount) { ... }
      // Error--subclass method cannot be more private
   ...
}

BankAccount account = new CheckingAccount();
account.withdraw(100000); // Should CheckingAccount.withdraw be called?

public class BankAccount
{
   ...
   protected double balance;
}

Implementing an Employee Hierarchy for Payroll Processing

This Worked Example shows how to implement payroll processing that works for different kinds of employees.

In Java, every class that is declared without an explicit extends clause automatically extends the class Object. That is, the class Object is the direct or indirect superclass of every class in Java (see Figure 7).

Figure 10.7. The Object Class Is the Superclass of Every Java Class

Of course, the methods of the Object class are very general. Here are the most useful ones:

It is a good idea for you to override these methods in your classes.

Rectangle box = new Rectangle(5, 10, 20, 30);
String     =  box.toString();  state.
   // Sets s to "java.awt.Rectangle[x=5,y=10,width=20,height=30]"

"box=" + box;

"box=java.awt.Rectangle[x=5,y=10,width=20,height=30]"

int age = 18;
String s = "Harry's age is " + age;
   // Sets s to "Harry's age is 18"

BankAccount momsSavings = new BankAccount(5000);
String s = momsSavings.toString();
   // Sets s to something like "BankAccount@d24606bf"

public class BankAccount
{
   ...
   public String toString()
   {
      return "BankAccount[balance=" + balance + "]";
   }
}

BankAccount momsSavings = new BankAccount(5000);
String s = momsSavings.toString();
   // Sets s to "BankAccount[balance=5000]"

Overriding the equals Method

The equals method is called whenever you want to compare whether two objects have the same contents:

if (coin1.equals(coin2)) ...
   // Contents are the same--see Figure 8

This is different from the test with the == operator, which tests whether the two references are to the same object:

if (coin1 == coin2) ...
   // Objects are the same--see Figure 9

Note

When implementing the equals method, test whether two objects have equal state.

Figure 10.8. Two References to Equal Objects

Figure 10.9. Two References to the Same Object

Let us implement the equals method for the Coin class. You need to override the equals method of the Object class:

public class Coin
{
    ...
   public boolean equals(Object otherObject)
   {
      ...
   }
    ...
}

Now you have a slight problem. The Object class knows nothing about coins, so it declares the otherObject parameter of the equals method to have the type Object. When overriding the method, you are not allowed to change the parameter type. To overcome this problem, cast the parameter to the class Coin:

Coin other = (Coin) otherObject;

Then you can compare the two coins.

public boolean equals(Object otherObject)
{
   Coin other = (Coin) otherObject;
   return name.equals(other.name) && value == other.value;
}

Note that you must use equals to compare object references, but use == to compare numbers.

When you override the equals method, you should also override the hashCode method so that equal objects have the same hash code—see Chapter 16 for details.

The clone Method

You know that copying an object reference simply gives you two references to the same object:

BankAccount account = new BankAccount(1000);
BankAccount account2 = account;
account2.deposit(500);
   // Now both account and account2 refer to a bank account with a balance of 1500

What can you do if you actually want to make a copy of an object? That is the purpose of the clone method. The clone method must return a new object that has an identical state to the existing object (see Figure 10).

Note

The clone method makes a new object with the same state as an existing object.

Implementing the clone method is quite a bit more difficult than implementing the toString or equals methods—see Special Topic 10.6 on page 452 for details.

Let us suppose that someone has implemented the clone method for the Bank-Account class. Here is how to call it:

BankAccount clonedAccount = (BankAccount) account.clone();

The return type of the clone method is the class Object. When you call the method, you must use a cast to convince the compiler that account.clone() really has the same type as clonedAccount.

Figure 10.10. Cloning Objects

16. Can you implement equals in terms of toString? Should you?

Supply toString in All Classes

If you have a class whose toString() method returns a string that describes the object state, then you can simply call System.out.println(x) whenever you need to inspect the current state of an object x. This works because the println method of the PrintStream class invokes x.toString() when it needs to print an object, which is extremely helpful if there is an error in your program and the objects don't behave the way you think they should. You can simply insert a few print statements and peek inside the object state during the program run. Some debuggers can even invoke the toString method on objects that you inspect.

Sure, it is a bit more trouble to write a toString method when you aren't sure your program ever needs one—after all, it might work correctly on the first try. Then again, many programs don't work on the first try. As soon as you find out that yours doesn't, consider adding those toString methods to help you debug the program.

Inheritance and the toString Method

You just saw how to write a toString method: Form a string consisting of the class name and the names and values of the instance variables. However, if you want your toString method to be usable by subclasses of your class, you need to work a bit harder. Instead of hardcoding the class name, you should call the getClass method to obtain a class object, an object of the Class class that describes classes and their properties. Then invoke the getName method to get the name of the class:

public String toString()
{
   return getClass().getName() + "[balance=" + balance + "]";
}

Then the toString method prints the correct class name when you apply it to a subclass, say a SavingsAccount.

SavingsAccount momsSavings = ... ;
System.out.println(momsSavings);
// Prints "SavingsAccount[balance=10000]"

Of course, in the subclass, you should override toString and add the values of the subclass instance variables. Note that you must call super.toString to get the superclass instance variables—the subclass can't access them directly.

public class SavingsAccount extends BankAccount
{
   public String toString()
   {
      return super.toString() + "[interestRate=" + interestRate + "]";
   }
}

Now a savings account is converted to a string such as SavingsAccount[balance= 10000][inter-estRate=5]. The brackets show which instance variables belong to the superclass.

Declaring the equals Method with the Wrong Parameter Type

Consider the following, seemingly simpler, version of the equals method for the Coin class:

public boolean equals(Coin other) // Don't do this!
{
   return name.equals(other.name) && value == other.value;
}

Here, the parameter of the equals method has the type Coin, not Object.

Unfortunately, this method does not override the equals method in the Object class. Instead, the Coin class now has two different equals methods:

boolean equals(Coin other) // Declared in the Coin class
boolean equals(Object otherObject) // Inherited from the Object class

This is error-prone because the wrong equals method can be called. For example, consider these variable declarations:

Coin aCoin = new Coin(0.25, "quarter");
Object anObject = new Coin(0.25, "quarter");

The call aCoin.equals(anObject) calls the second equals method, which returns false.

The remedy is to ensure that you use the Object type for the explicit parameter of the equals method.

Inheritance and the equals Method

You just saw how to write an equals method: Cast the otherObject parameter to the type of your class, and then compare the instance variables of the implicit parameter and the other parameter.

But what if someone called coin1.equals(x) where x wasn't a Coin object? Then the bad cast would generate an exception, and the program would die. Therefore, you first want to test whether otherObject really is an instance of the Coin class. The easiest test would be with the instanceof operator. However, that test is not specific enough. It would be possible for otherObject to belong to some subclass of Coin. To rule out that possibility, you should test whether the two objects belong to the same class. If not, return false.

if (getClass() != otherObject.getClass()) return false;

Moreover, the Java language specification demands that the equals method return false when otherObject is null.

Here is an improved version of the equals method that takes these two points into account:

public boolean equals(Object otherObject)
{
   if (otherObject == null) return false;
   if (getClass() != otherObject.getClass())
      return false;

   Coin other = (Coin) otherObject;
   return name.equals(other.name) && value == other.value;
}

When you implement equals in a subclass, you should first call equals in the superclass, like this:

public CollectibleCoin extends Coin
{
   private int year;
   ...
   public boolean equals(Object otherObject)
   {
      if (!super.equals(otherObject)) return false;

      CollectibleCoin other = (CollectibleCoin) otherObject;
      return year == other.year;
   }
}

Clone Mutable Instance Variables in Accessor Methods

Consider the following class:

public class Customer
{
   private String name;
   private BankAccount account;

   public Customer(String aName)
   {
      name = aName;
       account = new BankAccount();
   }

   public String getName()
   {
      return name;
   }


    public BankAccount getAccount()
    {
      return account;
    }
}

This class looks very boring and normal, but the getAccount method has a curious property. It breaks encapsulation, because anyone can modify the object state without going through the public interface:

Customer harry = new Customer("Harry Handsome");
BankAccount account = harry.getAccount();
   // Anyone can withdraw money!
account.withdraw(100000);

Maybe that wasn't what the designers of the class had in mind? Maybe they wanted class users only to inspect the account? In such a situation, you should clone the object reference:

public BankAccount getAccount();
{

return (BankAccount) account.clone();
}

Do you also need to clone the getName method? No—that method returns a string, and strings are immutable. It is safe to give out a reference to an immutable object.

Implementing the clone Method

The Object.clone method is the starting point for the clone methods in your own classes. It creates a new object of the same type as the original object. It also automatically copies the instance variables from the original object to the cloned object. Here is a first attempt to implement the clone method for the BankAccount class:

public class BankAccount
{
   ...
   public Object clone()
   {
      // Not complete
      Object clonedAccount = super.clone();
      return clonedAccount;
   }
}

However, this Object.clone method must be used with care. It only shifts the problem of cloning by one level; it does not completely solve it. Specifically, if an object contains a reference to another object, then the Object.clone method makes a copy of that object reference, not a clone of that object. The figure below shows how the Object.clone method works with a Customer object that has references to a String object and a BankAccount object. As you can see, the Object.clone method copies the references to the cloned Customer object and does not clone the objects to which they refer. Such a copy is called a shallow copy.

The Object.clone Method Makes a Shallow Copy

There is a reason why the Object.clone method does not systematically clone all sub-objects. In some situations, it is unnecessary. For example, if an object contains a reference to a string, there is no harm in copying the string reference, because Java string objects can never change their contents. The Object.clone method does the right thing if an object contains only numbers, Boolean values, and strings. But it must be used with caution when an object contains references to other objects.

For that reason, there are two safeguards built into the Object.clone method to ensure that it is not used accidentally. First, the method is declared protected (see Special Topic 10.3 on page 439). This prevents you from accidentally calling x.clone() if the class to which x belongs hasn't declared clone to be public.

As a second precaution, Object.clone checks that the object being cloned implements the Cloneable interface. If not, it throws an exception. The Object.clone method looks like this:

public class Object
{
   protected Object clone()
         throws CloneNotSupportedException
   {
      if (this instanceof Cloneable)
      {
         // Copy the instance variables
         ...
      }
      else
         throw new CloneNotSupportedException();
   }
}

Unfortunately, all that safeguarding means that the legitimate callers of Object.clone() pay a price—they must catch that exception (see Chapter 11) even if their class implements Cloneable.

public class BankAccount implements Cloneable
{
    ...
   public Object clone()
   {
      try
      {
         return super.clone();
      }
      catch (CloneNotSupportedException e)
      {
         // Can't happen because we implement Cloneable but we still must catch it.
         return null;
      }
   }
}

If an object contains a reference to another mutable object, then you must call clone for that reference. For example, suppose the Customer class has an instance variable of class Bank-Account. You can implement Customer.clone as follows:

public class Customer implements Cloneable
{
   private String name;
   private BankAccount account;
    ...
   public Object clone()
   {
      try
      {

Customer cloned = (Customer) super.clone();
         cloned.account = (BankAccount) account.clone();
         return cloned;
      }
      catch(CloneNotSupportedException e)
      {
         // Can't happen because we implement Cloneable
         return null;
      }
   }
}

Enumeration Types Revisited

In Special Topic 5.3, we introduced the concept of an enumeration type: a type with a finite number of values. An example is

public enum FilingStatus { SINGLE, MARRIED }

In Java, enumeration types are classes with special properties. They have a finite number of instances, namely the objects declared inside the braces. For example, there are exactly two objects of the FilingStatus class: FilingStatus.SINGLE and FilingStatus.MARRIED. Since Filing-Status has no public constructor, it is impossible to construct additional objects.

Enumeration classes extend the Enum class, from which they inherit toString and clone methods. The toString method returns a string that equals the object's name. For example, FilingStatus.SINGLE.toString() returns "SINGLE". The clone method returns the given object without making a copy. After all, it should not be possible to generate new objects of an enumeration class.

The Enum class inherits the equals method from its superclass, Object. Thus, two enumeration constants are only considered equal when they are identical.

You can add your own methods and constructors to an enumeration class, for example

public enum CoinType
{
    private double value;
    PENNY(0.01), NICKEL(0.05), DIME(0.1), QUARTER(0.25);
    CoinType(double aValue) { value = aValue; }
    public double getValue() { return value; }
}

This CoinType class has exactly four instances: CoinType.PENNY, CoinType.NICKEL, CoinType.DIME, and CoinType.QUARTER. If you have one of these four CoinType objects, you can apply the getValue method to obtain the coin's value.

Note that there is a major philosophical difference between this CoinType class and the Coin class that we have discussed elsewhere in this chapter. A Coin object represents a particular coin. You can construct as many Coin objects as you like. Different Coin objects can be equal to another. We consider two Coin objects equal when their names and values match. However, CoinType describes a type of coins, not an individual coin. The four CoinType objects are distinct from each other.

Scripting Languages

Suppose you work for an office where you must help with the bookkeeping. Suppose that every sales person sends in a weekly spreadsheet with sales figures. One of your jobs is to copy and paste the individual figures into a master spreadsheet and then copy and paste the totals into a word processor document that gets e-mailed to several managers. This kind of repetitive work can be intensely boring. Can you automate it?

It would be a real challenge to write a Java program that can help you—you'd have to know how to read a spreadsheet file, how to format a word processor document, and how to send e-mail.

Fortunately, many office software packages include scripting languages .These are programming languages that are integrated with the software for the purpose of automating repetitive tasks. The best-known of these scripting languages is Visual Basic Script, which is a part of the Microsoft Office suite. The Macintosh operating system has a language called AppleScript for the same purpose.

In addition, scripting languages are available for many other purposes. JavaScript is used for web pages. (There is no relationship between Java and JavaScript—the name JavaScript was chosen for marketing reasons.) Tcl (short for "tool control language" and pronounced "tickle") is an open source scripting language that has been ported to many platforms and is often used for scripting software test procedures. Shell scripts are used for automating software configuration, backup procedures, and other system administration tasks.

Scripting languages have two features that makes them easier to use than full-fledged programming languages such as Java. First, they are interpreted.The interpreter program reads each line of program code and executes it immediately without compiling it first. That makes experimenting much more fun—you get immediate feedback. Also, scripting languages are usually loosely typed, meaning you don't have to declare the types of variables. Every variable can hold values of any type. For example, the figure below shows a scripting session with the JavaScript implementation that is included in the Java Development Kit.

Scripting Java Classes with JavaScript

This version of JavaScript allows you to manipulate Java objects. The script stores frame and label objects in variables that are declared without types. It then calls methods that are executed immediately, without compilation. The frame pops up as soon as the line with the setVisible command is entered. In recent years, authors of computer viruses have discovered how scripting languages simplify their lives. The famous "love bug" is a Visual Basic Script program that is sent as an attachment to an e-mail. The e-mail has an enticing subject line "I love you" and asks the recipient to click on an attachment masquerading as a love letter. In fact, the attachment is a script file that is executed when the user clicks on it. The script creates some damage on the recipient's computer and then, through the power of the scripting language, uses the Outlook e-mail client to mail itself to all addresses found in the address book. Try programming that in Java! By the way, the person suspected of authoring that virus was a student who had submitted a proposal to write a thesis researching how to write such programs. Perhaps not surprisingly, the proposal was rejected by the faculty.

Why do we still need Java if scripting is easy and fun? Scripts often have poor error checking and are difficult to adapt to new circumstances. Scripting languages lack many of the structuring and safety mechanisms (such as classes and type checking by the compiler) that are important for building robust and scalable programs.

As you add more user-interface components to a frame, the frame can get quite complex. Your programs will become easier to understand when you use inheritance for complex frames.

To do so, design a subclass of JFrame. Store the components as instance variables. Initialize them in the constructor of your subclass. If the initialization code gets complex, simply add some helper methods.

Here, we carry out this process for the investment viewer program in Chapter 9.

public class InvestmentFrame extends JFrame
{
   private JButton button;
   private JLabel label;
   private JPanel panel;
   private BankAccount account;

   public InvestmentFrame()
   {
      account = new BankAccount(INITIAL_BALANCE);

      // Use instance variables for components
      label = new JLabel("balance: " + account.getBalance());

      // Use helper methods
      createButton();
      createPanel();

      setSize(FRAME_WIDTH, FRAME_HEIGHT);
   }

   private void createButton()
    {

button = new JButton("Add Interest");
      ActionListener listener = new AddInterestListener();
      button.addActionListener(listener);
   }

   private void createPanel()
   {
      panel = new JPanel();
      panel.add(button);
      panel.add(label);
      add(panel);
   }
   ...
}

This approach differs from the programs in Chapter 9. In those programs, we simply configured the frame in the main method of a viewer class.

It is a bit more work to provide a separate class for the frame. However, the frame class makes it easier to organize the code that constructs the user-interface elements.

Of course, we still need a class with a main method:

public class InvestmentViewer2
{
   public static void main(String[] args)
   {
      JFrame frame = new InvestmentFrame();
      frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      frame.setVisible(true);
   }
}

18. Why does the InvestmentFrame constructor call setSize(FRAME_WIDTH, FRAME_HEIGHT), whereas the main method of the investment viewer class in Chapter 9 called frame.setSize(FRAME_WIDTH, FRAME_HEIGHT)?

public class InvestmentFrame extends JFrame
{
   public static void main(String[] args)
   {
      JFrame frame = new InvestmentFrame();
      frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
      frame.setVisible(true);
   }

   public InvestmentFrame()
s   {
      account = new BankAccount(INITIAL_BALANCE);

// Use instance variables for components
      label = new JLabel("balance: " + account.getBalance());

      // Use helper methods
      createButton();
      createPanel();

      setSize(FRAME_WIDTH, FRAME_HEIGHT);
   }
   ...
}

java.lang.Cloneable                        java.lang.Object
java.lang.CloneNotSupportedException          clone
                                              toString

SavingsAccount b = new SavingsAccount(10);
b.deposit(5000);
b.withdraw(b.getBalance() / 2);
b.addInterest();

Sandwich x = new Sandwich();
Sub y = new Sub();

public class D extends B
{
    public void f()
    {
      this.g(); // 1
    }
    public void g()
    {
      super.g(); // 2
    }
   ...
}

public class AccountPrinter
{
   public static void main(String[] args)
   {
      SavingsAccount momsSavings
            = new SavingsAccount(0.5);

      CheckingAccount harrysChecking
            = new CheckingAccount(0);

      ...
      endOfMonth(momsSavings);
      endOfMonth(harrysChecking);
      printBalance(momsSavings);
      printBalance(harrysChecking);
   }

   public static void endOfMonth(SavingsAccount savings)
   {
       savings.addInterest();
   }

   public static void endOfMonth(CheckingAccount checking)
   {
       checking.deductFees();
   }

public static void printBalance(BankAccount account)
   {
      System.out.println("The balance is $"
            + account.getBalance());
   }
}

Programming Exercises

P10.1 Enhance the addInterest method of the SavingsAccount class to compute the interest on the minimum balance since the last call to addInterest. Hint: You need to modify the withdraw method as well, and you need to add an instance variable to remember the minimum balance.

P10.2 Add a TimeDepositAccount class to the bank account hierarchy. The time deposit account is just like a savings account, but you promise to leave the money in the account for a particular number of months, and there is a $20 penalty for early withdrawal. Construct the account with the interest rate and the number of months to maturity. In the addInterest method, decrement the count of months. If the count is positive during a withdrawal, charge the withdrawal penalty.

P10.3 Add a class NumericQuestion to the question hierarchy of How To 10.1. If the response and the expected answer differ by no more than 0.01, then accept it as correct.

P10.4 Add a class FillInQuestion to the question hierarchy of How To 10.1. An object of this class is constructed with a string that contains the answer, surrounded by _ _, for example, "The inventor of Java was _James Gosling_". The question should be displayed as

The inventor of Java was __s_

P10.5 Modify the checkAnswer method of the Question class of How To 10.1 so that it does not take into account different spaces or upper/lowercase characters. For example, the response " JAMES gosling" should match an answer of "James Gosling".

P10.6 Add a class MultiChoiceQuestion to the question hierarchy of How To 10.1 that allows multiple correct choices. The respondent should provide all correct choices, separated by spaces. Provide instructions in the question text.

P10.7 Add a class AnyCorrectChoiceQuestion to the question hierarchy of How To 10.1 that allows multiple correct choices. The respondent should provide any one of the correct choices. The answer string should contain all of the correct choices, separated by spaces.

P10.8 Add a method addText to the Question class of How To 10.1 and provide a different implementation of ChoiceQuestion that calls addText rather than storing an array list of choices.

P10.9 Provide toString and equals methods for the Question and ChoiceQuestion classes of How To 10.1.

P10.10 Implement a subclass Square that extends the Rectangle class. In the constructor, accept the x- and y-positions of the center and the side length of the square. Call the setLocation and setSize methods of the Rectangle class. Look up these methods in the documentation for the Rectangle class. Also supply a method getArea that computes and returns the area of the square. Write a sample program that asks for the center and side length, then prints out the square (using the toString method that you inherit from Rectangle) and the area of the square.

P10.11 Implement a superclass Person. Make two classes, Student and Instructor, that inherit from Person. A person has a name and a year of birth. A student has a major, and an instructor has a salary. Write the class declarations, the constructors, and the methods toString for all classes. Supply a test program that tests these classes and methods.

P10.12 Make a class Employee with a name and salary. Make a class Manager inherit from Employee. Add an instance variable, named department, of type String. Supply a method toString that prints the manager's name, department, and salary. Make a class Executive inherit from Manager. Supply appropriate toString methods for all classes. Supply a test program that tests these classes and methods.

P10.13 Reorganize the bank account classes as follows. In the BankAccount class, introduce an abstract method endOfMonth with no implementation. Rename the addInterest and deductFees methods into endOfMonth in the subclasses. Which classes are now abstract and which are concrete? Write a static method void test(BankAccount account) that makes five transactions and then calls endOfMonth. Test it with instances of all concrete account classes.

P10.14 Implement an abstract class Vehicle and concrete subclasses Car and Truck. A vehicle has a position on the screen. Write methods draw that draw cars and trucks as follows:

Then write a method randomVehicle that randomly generates Vehicle references, with an equal probability for constructing cars and trucks, with random positions. Call it 10 times and draw all of them.

P10.15 Write a program that prompts the user for an integer, using a JOptionPane, and then draws as many rectangles at random positions in a component as the user requested. Use inheritance for your frame class.

P10.16 Write a program that asks the user to enter an integer n into a JOptionPane, and then draws an n-by-n grid. Use inheritance for the frame class.

* *******
*     * *
* ***** *
* * *   *
* * *** *
*   *   *
*** * * *
*     * *
******* *