Overriding a method, such as toString

Your class inherits a method it does not like. Overriding is writing your own version, with the same header, in your own class, so that from then on your objects use yours. The parent's version is still there and is still what everybody else uses. Yours is what runs when the object in front of Java is one of yours.

Start with the one everybody overrides

Every class in Java extends Object, so every class already has a toString. Print a student without doing anything about it and you get this:

Student@1a2b3c

That is the class name, an @, and a number Java computed for the object (its hash code, in hexadecimal). It tells you nothing about the student's data. Write your own and the same println tells you something:

@Override
public String toString()
{
    return "Student{name=" + this.name + ", gpa=" + this.gpa + "}";
}

Student{name=Ada, gpa=3.9}

You never call toString in that example, and it runs anyway. Java calls it for you any time it needs text from an object: inside System.out.println(student), and on either side of a + when the other side is a String. That is why a broken toString shows up in output you did not think went near it.

What makes it an override and not a new method

Java decides that by the header, and it is strict about it. To replace the parent's method, yours needs the same name, the same parameter list in the same order, the same return type or a subclass of it, and access that is not narrower than the parent's. Change the parameter list at all and you have not replaced anything. You have added a second, unrelated method that happens to share a name, and the parent's version is still sitting there, still the one that gets called.

That failure is silent. The classic case is equals:

// looks careful, replaces nothing
public boolean equals(Student other)
{
    return this.name.equals(other.name);
}

Every object inherits equals(Object obj), with an Object parameter. A method taking a Student has a different parameter list, so it does not override; it sits beside the inherited one. Library code that calls equals calls the inherited version, which is true only when both variables refer to the same object, and your method never runs at all. Nothing in the compiler or at run time says a word.

Which body runs

2 types are in play on these lines, and they do different jobs.

Plant p1 = new Cactus();
Plant p2 = new Fern("Boston fern");

The variable's type decides what you may call. The object's type decides which body runs. Java cannot settle the second question while compiling, because the same variable could hold a Cactus on one run and a Fern on the next. It settles it at the moment of the call. It starts at the object's own class and walks up toward the parent until it finds a body, and that body runs (dynamic dispatch).

So a method in the parent can call a method the parent has no body for.

public abstract class Plant
{
    private String name;
    private int waterDays;

    // protected constructor as before

    public abstract boolean isIndoor();

    public String careNote()
    {
        if (isIndoor())
        {
            return this.name + " stays inside";
        }
        return this.name + " goes outside";
    }
}

Plant does not know whether a plant lives indoors, and it does not need to. When careNote runs on a Cactus, the isIndoor() call inside it runs Cactus's version, which returns false. The same careNote on a Fern runs Fern's version, which returns true.

cactus goes outside
Boston fern stays inside

The shared sentence is written once, in the class that owns the fields. Each child supplies only the part that differs. Copying careNote into every child also works, and then every copy has to be kept the same by hand.

Calling the parent's version on purpose

Overriding does not throw the parent's version away. super.toString() reaches past your own method to the one you replaced, which is useful when your version is the parent's plus something.

public class GradStudent extends Student
{
    private String advisor;

    @Override
    public String toString()
    {
        return super.toString() + ", advised by " + this.advisor;
    }
}

The child does not repeat what the parent already knows how to print. Write this.toString() there instead of super.toString() and the method calls itself until the program stops with a StackOverflowError.

In the practice APE

The Inheritance problem uses this lesson. Its header comments are the specification.

Here is the same kind of task on the Plant family. Plant's toString returns the name, then ", water every ", then the number of days, then " days". Write Fern's toString from its comment.

// Fern: return what Plant's toString returns, followed by
// ", keep out of direct sun"
public String toString()

@Override
public String toString()
{
    return super.toString() + ", keep out of direct sun";
}

Boston fern, water every 3 days, keep out of direct sun

Readiness check

Work each one on paper and write the answer down before you open it.

public class TreeFern extends Fern
{
    public TreeFern()
    {
        super("tree fern");
    }

    @Override
    public boolean isIndoor()
    {
        return false;
    }
}