Polymorphism, the Object Class, and is-a versus has-a

Two types, two jobs

In Employee e = new Manager("An", 8, 4); the variable has a declared type (Employee) and the object has an actual type (Manager). The compiler checks the declared type: e.bonus() fails to compile if bonus exists only in Manager. At run time Java uses the actual type to decide which body executes, so e.pay() runs the Manager version. That late decision is dynamic binding, and the ability of one line of code to run different bodies is polymorphism.

The payoff is an array or list of the superclass type holding mixed objects: one loop calling pay() makes every element behave according to its own class, and adding a new subclass later requires no change to the loop.

Everything extends Object

Every class inherits from Object, whose two methods matter here. The default toString() prints a class name and a hash code, which is useless, so classes override it; System.out.println(obj) calls toString() automatically. The default equals() compares references — true only when both variables point at the very same object — so a class that wants value comparison must override it. Note that == on objects always compares references and is never overridable.

is-a versus has-a

Use extends only for is-a (a Manager is an Employee). When one class merely contains another — a Library has Book objects — store it as an instance variable. That is composition, and it is the right answer far more often than inheritance.