Liskov Substitution: fix a subtype that breaks callers
Make every subclass work wherever its base type already works.
Watch the narrated video
Every step
Problem
Steps 1–5Refactor
Steps 6–9Payoff
Steps 10–11Recap
Steps 12–13The code: before and after
Before
abstract class PaymentMethod {
public abstract void charge(int amount);
public abstract void refund(int amount);
}
class Card extends PaymentMethod {
public void charge(int amount) {
System.out.println("card charged " + amount);
}
public void refund(int amount) {
System.out.println("card refunded " + amount);
}
}
class Checkout {
void pay(PaymentMethod method, int amount) {
method.charge(amount);
}
}
class Returns {
void giveBack(PaymentMethod method, int amount) {
method.refund(amount);
}
}
class Shop {
public static void main(String[] args) {
Card card = new Card();
new Checkout().pay(card, 40);
new Returns().giveBack(card, 40);
}
}After
interface Refundable {
void refund(int amount);
}
abstract class PaymentMethod {
public abstract void charge(int amount);
}
class Card extends PaymentMethod implements Refundable {
public void charge(int amount) {
System.out.println("card charged " + amount);
}
public void refund(int amount) {
System.out.println("card refunded " + amount);
}
}
class GiftCard extends PaymentMethod {
public void charge(int amount) {
System.out.println("gift card charged " + amount);
}
}
class Checkout {
void pay(PaymentMethod method, int amount) {
method.charge(amount);
}
}
class Returns {
void giveBack(Refundable method, int amount) {
method.refund(amount);
}
}
class Shop {
public static void main(String[] args) {
Card card = new Card();
new Checkout().pay(card, 40);
new Returns().giveBack(card, 40);
GiftCard gift = new GiftCard();
new Checkout().pay(gift, 25);
// new Returns().giveBack(gift, 25); // does not compile
}
}Transcript, step by step
Problem
Step 1: A shop that takes cards Before
Payment Method is an abstract class, and every way to pay extends it. It promises its callers a charge method and a refund method, and that promise is its contract. Card is the one way the shop has to pay, and it can charge and refund. Checkout and Returns are the callers, the code that uses Payment Method, and they only know that base type. Shop pays forty dollars with the card and gives forty back, so it prints card charged forty and card refunded forty. Every payment so far could be charged and refunded, so putting both methods in the base type made sense.
Step 2: Finance adds gift cards Code smell
Finance adds gift cards, and a gift card can pay, but its money is never refunded. The quick way adds Gift Card as a subclass of Payment Method, and its charge prints gift card charged. The base type forces it to have a refund too, so this one throws Unsupported Operation Exception. Shop pays twenty five with a gift card, then gives it back. Everything compiles, so what happens when Shop runs this last line? It crashes, because give back calls refund, and refund throws.
Step 3: Returns checks the class Code smell
To stop the crash, the developer puts a type check at the top of give back. If the method is a Gift Card, it prints gift card no refund and returns early. So the program runs to the end again, with two gift card lines in its output.
Step 4: A subtype that breaks its contract Code smell
Gift Card is a subtype that can't keep its contract, so a caller crashed, until Returns added a type check. The contract includes refund here, the gift card breaks it here, and Returns now has to check the exact class here. And the base type still says refund is safe to call on any payment, which is no longer true.
Step 5: Liskov Substitution Principle
The Liskov Substitution Principle, from Barbara Liskov, says code that uses a base type must work with any subtype. In plain words, a subtype keeps its base type's contract. Gift Card breaks it, and the type check in Returns is the symptom.
Refactor
Step 6: Refactor first Back it out
So let's take the gift card and the type check out again. We'll refactor first, so the contract fits every payment, and then add gift cards back.
Step 7: Name the refund Extract Interface
First we give refund a type of its own, an interface called Refundable with that one method. Card implements it as well, and its refund method already matches, so nothing inside Card changes. Payment Method still declares refund, and the next two moves fix that.
Step 8: Returns asks for Refundable Change Function Declaration
Next, give back takes a Refundable instead of a Payment Method, because refund is the only thing it calls. Shop still passes the card, and a card is a Refundable, so it prints the same two lines.
Step 9: Refund leaves the base type Push Down Method
Now no caller needs refund from Payment Method, so it moves down out of the base type. The contract of Payment Method is charge only, and refund lives in Refundable, which Card implements.
Payoff
Step 10: Gift cards, again Payoff
So now gift cards can come back in. Gift Card extends Payment Method with charge only, so there's no refund method and nothing to throw. Shop pays twenty five with it, and the program prints gift card charged twenty five. The give back line from before now fails at compile time here, because Gift Card isn't a Refundable.
Step 11: Every subtype keeps the contract Payoff
Card, Checkout and Returns did not change to add gift cards. The contract has no refund here, the gift card has nothing to break here, and Returns has no type check here. Gift Card can stand in for Payment Method everywhere, because the contract holds only what every payment can do. But the split has a cost: code holding only a Payment Method now needs a cast to Refundable to refund. That's the Liskov Substitution Principle, kept by every subclass of Payment Method.
Recap
Step 12: Where we started, where we ended Before / after
On the left, Payment Method promised refund to every payment, so the first one that couldn't refund had to throw. On the right, Payment Method promises charge only, and refund has its own interface. Gift Card keeps the whole contract it inherits, and Returns asks only for something it can refund.
Step 13: When to reach for it Takeaways
Reach for it when a subclass overrides a method only to throw, or when its callers need a special case for it. Skip it when the subtype can keep the contract, like gift cards that pay back in store credit. You'll spot it by a caller that checks the exact class with instance of, or an override that throws Unsupported Operation Exception. Java's own Collection marks add as an optional operation, so calling add on a List dot of list throws.