Liskov Substitution Principle

The principle says a subclass must be usable anywhere its parent is expected, without the caller needing to know or care. Formally, if code works correctly with the parent type, it must work correctly when given the child type instead. That is what makes polymorphic dispatch safe rather than a trap.

public class Main {
    public static void main(String[] args) {
        java.util.List<Account> accounts = new java.util.ArrayList<>();
        accounts.add(new SavingsAccount(100.0));
        accounts.add(new FixedDepositAccount(100.0));
        for (Account a : accounts) {
            try {
                System.out.println(a.type() + " withdraw -> " + a.withdraw(50.0));
            } catch (RuntimeException e) {
                System.out.println(a.type() + " refused: " + e.getMessage());
            }
        }
    }
}

class Account {
    protected double balance;
    Account(double balance) { this.balance = balance; }
    String type() { return "account"; }
    double withdraw(double amount) {
        if (amount > balance) { throw new IllegalStateException("insufficient funds"); }
        balance = balance - amount;
        return balance;
    }
}

class SavingsAccount extends Account {
    SavingsAccount(double balance) { super(balance); }
    String type() { return "savings"; }
}

class FixedDepositAccount extends Account {
    FixedDepositAccount(double balance) { super(balance); }
    String type() { return "fixed deposit"; }
    double withdraw(double amount) {
        throw new UnsupportedOperationException("fixed deposits cannot be withdrawn early");
    }
}

The example shows a violation. The fixed deposit account inherits withdraw and then refuses to honour it, so a caller holding an Account reference cannot rely on the call succeeding. The output shows the savings account working normally while the fixed deposit is refused, and the caller had no way to predict which would happen from the type alone.

There are several ways to break the contract, and the exception is the most obvious. Others include narrowing the visibility of an inherited method, returning a narrower type than the parent promised, changing the meaning or units of a parameter or a return value, and adding new checked exceptions to an overridden method.

The fix is to make the hierarchy match the behaviour rather than the vocabulary. If a fixed deposit genuinely cannot be withdrawn, then withdraw should not be part of the contract that all accounts promise. Move it to a narrower interface that only the accounts that support it implement, and let the caller that needs to withdraw depend on that narrower type. The class named account then becomes an honest abstraction again.

Start by writing the substitutability test as a set of assertions about behaviour rather than about types. For each method the parent promises, write down what a caller is entitled to expect, and check that the subclass honours all of it. The fixed deposit example would have a test that says withdrawing from an account leaves a smaller balance, and the fixed deposit would fail it.

Then write the tests against the parent type, not against the concrete classes. A test suite that exercises a behaviour through the parent reference and is run for every subclass in the hierarchy is a direct check of the contract, and it catches the violation at the point where it is introduced rather than months later.

Third, use a contract test or property test where the parent has invariants. Rather than asserting on concrete return values, assert on the relationship, such as that the balance never increases after a withdrawal or that a square's area always equals the square of its side. Contract tests can be shared by every implementation and catch drift automatically.

Fourth, review the signatures. The compiler enforces the mechanical parts, such as the return type, the visibility and the exception list, so a signature change that narrows the contract will not compile. What the compiler cannot check is a change in meaning, and that is what the behavioural tests and the review are for.

The final point is about design rather than testing. A hierarchy that keeps producing violations is telling you that the base type is modelled as the union of what the subtypes can do, rather than the intersection. The durable fix is to split the contract until the base type describes only what every subtype genuinely supports.