Demo: month-end processing without a single type check

Examples

Example 1: steps 1 to 4, the refactoring (simple)

Steps 2 and 3: add the parent default, then the two overrides.

// in Account:
void monthEnd() { }                      // default: nothing to do

// in SavingsAccount:
@Override void monthEnd() { deposit(getBalance() * rate); }

// in CheckingAccount:
@Override void monthEnd() { withdraw(fee); }

Step 4: the loop becomes

for (Account a : accounts) {
    a.monthEnd();
    System.out.println(a.getOwner() + ": " + a.getBalance());
}

With Ana's savings account (1000.0 at 2%) and Omar's checking account (500.0 with a 5.0 fee), the output is the same as the old chain produced:

Ana: 1020.0
Omar: 495.0

Each of the four steps compiles and runs on its own. If your output differs from the old loop's at this point, stop and fix it before going on: do not move to step 5 with a broken refactoring.

Example 2: step 5, the planted mistake (practical)

Now imagine a typing slip in SavingsAccount, written without @Override:

void monthend() { deposit(getBalance() * rate); }    // lowercase e: a different name

This compiles. monthend (lowercase e) is simply a brand-new method, unrelated to monthEnd. Nothing calls it. The loop calls monthEnd(), finds the parent's empty default, and does nothing:

Ana: 1000.0
Omar: 495.0

Ana received no interest, and there was no error and no exception, only a wrong number. In a real system, this is the kind of bug that reaches customers.

Now add the annotation:

@Override void monthend() { deposit(getBalance() * rate); }

Demo.java:15: error: method does not override or implement a method from a supertype
    @Override void monthend() { deposit(getBalance() * rate); }
    ^
1 error

The compiler now stops you immediately and points at the exact line. The Java API documentation for @Override says this is what the annotation is for: it is an error if the annotated method does not override a supertype method. Fix the spelling, remove nothing else, and the output is back to Ana: 1020.0.

The same protection covers the other half of the module's common mistakes, confusing overloading with overriding. A method such as void monthEnd(int days) in the subclass would also be rejected by @Override, because it overloads instead of overriding.

Example 3: step 6, a new type and an untouched loop (realistic)

Add a new class in its own place in the code. Do not edit the loop.

class BusinessAccount extends Account {
    BusinessAccount(String owner, double balance) { super(owner, balance); }
    @Override void monthEnd() { withdraw(25.0); }    // flat monthly charge
}

Add new BusinessAccount("Shop", 2000.0) to the array of accounts, which is data, not logic. Then run the same loop as before:

Ana: 1020.0
Omar: 495.0
Shop: 1975.0

The loop was not edited, and the new type is processed correctly. That is the lab's acceptance criterion, shown to hold.

A useful way to check it for the lab: compare the loop's text before and after adding the class, using your version-control tool or just by eye. If any line of the loop differs, the criterion is not met. The only places that should change are the new class and the line that creates an object of it.

For the lab, you may also report the results more neatly, and compute a total without any type check, using the balance difference rather than any type-specific knowledge:

double change = 0;
for (Account a : accounts) {
    double before = a.getBalance();
    a.monthEnd();
    change += a.getBalance() - before;
    System.out.printf("%-5s %8.2f%n", a.getOwner(), a.getBalance());
}
System.out.printf("net change: %.2f%n", change);

With Ana, Omar, Shop, a student account Lina (100.0, which inherits the empty default so no fee is charged), and a Gold account that deposits 15.0 each month, it prints:

Ana    1020.00
Omar    495.00
Shop   1975.00
Lina    100.00
Zed      65.00
net change: 5.00

The net change is 20 - 5 - 25 + 0 + 15 = 5, and the loop still contains no type check.