Reusing behavior with extends

Written Explanation

The problem: the same code twice

Imagine Account has an owner, a balance, deposit, and withdraw. A SavingsAccount needs all of that, plus an interest rate. If you copy Account, you now maintain two classes with identical code. When you find a bug in withdraw, you must remember to fix it in both. Programmers call this duplication, and it is a main source of bugs that fix themselves in one place only.

extends: declaring a kind-of relationship

Inheritance lets you write the shared code once. The keyword is extends:

class SavingsAccount extends Account {
    // new things only
}

Vocabulary you will see everywhere:

The Java tutorial on inheritance describes the subclass as inheriting the members of its superclass, and says it can add fields and methods of its own. In the family-tree picture, SavingsAccount is the child, Account is the parent, and the child receives the parent's traits.

What a subclass receives

When SavingsAccount extends Account, every SavingsAccount object can use the accessible members of Account as if it had written them itself. Whether a member is accessible follows the access rules from the previous module:

A private field is the subtle case. The SavingsAccount object does hold the parent's private data inside it, because the object must store the balance somewhere. But the subclass code cannot name that field. It can only reach it through the parent's public or protected methods. That is encapsulation still doing its job: a subclass does not get to break the parent's rules.

Constructors are the other exception. A constructor builds a particular class, so it is not handed down. The next lesson shows how a subclass constructor asks the parent's constructor to do its part.

New members and the family tree

A subclass is the parent plus something. It can add fields and methods that the parent does not have:

class SavingsAccount extends Account {
    private double rate;          // new field

    void addInterest() { ... }    // new method
}

A SavingsAccount object has everything from Account and also rate and addInterest(). The reverse is not true: a plain Account has no addInterest(). The parent knows nothing about its children, just as a parent's traits do not depend on what a child later becomes.

One parent only

A Java class has exactly one direct superclass. The language specification (JLS section 8.1.4) says the extends clause names a single class, so you cannot write class C extends A, B. A class without any extends has Object as its direct superclass, and Object is the top of every chain. So every class you have written so far already extends Object without saying so, and every class has a chain of ancestors ending at Object.

A class can have many children; it just cannot have many parents. A class can also implement interfaces, which is a different mechanism and a later topic.

The is-a test

Inheritance is a promise: a subclass object can be treated as a kind of its superclass. Before writing extends, say the sentence out loud:

• "A savings account is an account." Yes: extends fits.
• "A dog is an animal." Yes.
• "A car is an engine." No: a car has an engine.

If the sentence sounds wrong, extends is wrong, however much code it would save. Lesson 5 goes deeper into the alternative. Saving typing is a pleasant side effect of inheritance, not its purpose.

What the compiler says about private parent data

Because private members are not inherited, this does not compile:

class Account {
    private double balance = 100;
    double getBalance() { return balance; }
}

class SavingsAccount extends Account {
    void addBonus() {
        balance += 10;
    }
}

Main.java:8: error: balance has private access in Account
        balance += 10;
        ^
1 error

The fix is not to make balance public. Add a method to the parent that applies the rule (a deposit), and let the child call it.