Challenge 2: An Abstract Employee Class — Possible Solution
====================================================================

Employee.java:

public abstract class Employee {
    protected String name;

    public Employee(String name) {
        this.name = name;
    }

    public abstract double pay();

    public String summary() {
        return name + " earns " + pay();
    }
}

Manager.java:

public class Manager extends Employee {
    private double salary;

    public Manager(String name, double salary) {
        super(name);
        this.salary = salary;
    }

    @Override
    public double pay() {
        return salary;
    }

    public static void main(String[] args) {
        Manager m = new Manager("Alex", 95000.0);
        System.out.println(m.summary());
    }
}

Output:

    Alex earns 95000.0

Explanation:
Employee holds real state (name) and a real constructor, something an
interface could never do. pay() is abstract -- Employee has no idea
how any given employee is actually paid -- but summary() is fully
concrete and shared by every subclass, calling whichever pay()
implementation the actual runtime object supplies. Manager supplies
that missing piece.

WHY THIS WORKS AS AN ANSWER
------------------------------
This uses an abstract class specifically because shared state (name)
and a shared concrete method (summary()) are both needed alongside an
abstract method -- exactly the case the chapter identifies as the
deciding factor between an interface and an abstract class.