Overriding methods

Written Explanation

What overriding is

A subclass overrides an instance method when it declares a method with the same name, the same number and types of parameters, and the same return type as a method it inherited. The Oracle tutorial puts it this way: such a method in the subclass overrides the superclass method, and the subclass version is used for objects of the subclass.

class Animal {
    String speak() { return "..."; }
}

class Dog extends Animal {
    @Override
    String speak() { return "Woof"; }
}

A Dog object answers speak() with Woof; an Animal object still answers .... The parent is not changed.

Overriding is not adding

Change the name or the parameters and you have not overridden anything: you added a new method next to the inherited one. The tutorial notes that a method with the same name but a different parameter list is an overload, which neither hides nor overrides the original.

This is where the trap sits. Suppose you meant to override speak() but typed speek():

class Dog extends Animal {
    String speek() { return "Woof"; }
}

This compiles without complaint. new Dog().speak() prints ..., the parent's answer. The program is wrong, and nobody told you.

@Override: let the compiler check

Add the annotation and the compiler verifies your intention:

class Cat extends Animal {
    @Override
    String speek() { return "Meow"; }
}

Main.java:8: error: method does not override or implement a method from a supertype
    @Override
    ^
1 error

The tutorial says that @Override tells the compiler you intend to override a method, and that the compiler reports an error if no such method exists in a superclass. It costs ten characters and removes a whole class of silent bugs. It also tells the next reader: "this replaces something inherited." Make it a habit, as automatic as a semicolon.

Rules for an override

The access rule is easy to break. If the parent's method is public and you write the override without a modifier, you narrowed it:

Main.java:7: error: run() in C cannot override run() in P
    void run() { }
         ^
  attempting to assign weaker access privileges; was public

Why the rule exists: anyone allowed to call the parent's method must also be allowed to call the child's version.

Calling the parent's version

Use super.method() inside an override to run the parent's code and then add to it, instead of repeating it:

class Tool {
    String name() { return "tool"; }
    String use() { return "using " + name(); }
}

class Hammer extends Tool {
    @Override
    String name() { return "hammer"; }

    @Override
    String use() { return super.use() + "!"; }
}

new Hammer().use() prints using hammer!. Two things happen. super.use() runs the code in Tool.use(). Inside that code the call name() is made on the current object, which is a Hammer, so the hammer's name() runs. That "the real object decides" behavior is the heart of the next module; for now just notice it.

What cannot be overridden

• Constructors are not inherited, so there is nothing to override.
• private methods are not inherited and a child cannot see them. If a child declares a method with the same name, it is a separate, unrelated method; adding @Override to it gives the "does not override" error.
• static methods belong to the class, not to objects. A subclass static method with the same signature hides the parent's; it is not an override. The tutorial's example shows that which one runs depends on the class used in the call, not the object. Rule of thumb: do not declare a static method in a subclass with the same signature as a parent's static method.
• final methods cannot be overridden. That is the next lesson.

Do not weaken the promise

An override must still keep the promises the parent made. The parent's withdraw promises: "the balance never goes below zero." If a child's override breaks that promise silently, code written against Account can break.

A legitimate change of rules must be part of the design. A checking account with an overdraft is a different kind of account with an allowed negative balance, which the bank explicitly decided. A savings account that charges a fee and accidentally pushes the balance below zero is a bug. Example 3 shows that bug.