Abstract Classes & Interfaces

Why This Matters

This is the last chapter of new material. Two concepts close out OOP:

1. Abstract classes — the Java version of C++'s pure virtual classes from Chapter 12.
2. Interfaces — Java's killer feature. Pure contracts. Classes can implement many of them.

Together they let you specify what a type must do without specifying how. The Project 14 Pilgrim's Journey Engine — your final exam — uses both.

Abstract Classes

public abstract class Combatant {
    protected String name;
    protected int hp;

    public Combatant(String n, int h) { name = n; hp = h; }

    public abstract void takeTurn(Combatant opponent);  // no body

    public String getName() { return name; }  // concrete
}

• abstract class + abstract method = "you must implement this in a subclass."
• You cannot new Combatant(...) directly — only subclasses can be instantiated.
• Abstract classes can mix abstract methods, concrete methods, fields, and constructors. They are a partial implementation.

Interfaces — Pure Contracts

public interface Healable {
    void heal(int amount);
    boolean canBeHealed();
}

An interface declares only signatures (no bodies, no fields, no constructors). Any class that implements Healable must provide both methods.

public class Hero extends Combatant implements Healable {
    // override takeTurn (abstract from Combatant)
    // implement heal and canBeHealed (from Healable)
}

The Killer Feature: Multiple Implementation

A class extends one class but can implement many interfaces.

public class Wizard extends Combatant
                    implements Healable, Burnable {
    // ...
}

Wizard is a Combatant and Healable and Burnable. Code that takes any of those types can accept a Wizard. This is what C++ tried to do with multiple inheritance — and got messy. Java sidestepped it: single class chain, multiple interface contracts.

Cross-Cutting Capabilities

Interfaces can cut across unrelated class hierarchies. A Hero and a Plant both implement Healable — but they share no parent. Code that iterates ArrayList<Healable> can heal both without knowing about Hero or Plant at all.

Coach's Note — Theology has long worked in interfaces. The medieval scholastics talked about qua this and qua that — "considered as." A person qua sinner is one thing; qua image-bearer of God is another. Java interfaces are this move in code: a class declares "considered as Healable, I can do these things; considered as Burnable, these others."

When to Use Which

• Abstract class when there's shared implementation (fields, helper methods, default behaviors) AND the relationship is "is-a."
• Interface when you want to describe a capability that can cut across class hierarchies. No shared implementation.
• Real Java code often uses both: an abstract base class plus interfaces for cross-cutting behavior.

No Project This Week

Use the week to consolidate everything from Chapter 9 onward. Read Project 14 so you know what the final asks for. Re-do Drill 5 from Chapter 8 — but in Java this time. Sleep well.

← WEEK 14: POLYMORPHISM   ·   WEEK 16: THE FINAL →