How this handbook teaches

The goal is not to memorize 23 patterns or 17 solutions. The goal is to look at a new prompt, find the objects and the rules they protect, notice where change will come from, and write clean code that runs, inside a time box. So the handbook asks you to think before it explains.

• Try before you read. Every lesson opens with a short question. Answer it on paper first; getting it wrong is what makes the explanation stick.
• Pressure first, pattern second. Each pattern starts from the code smell it fixes and ends with when it is the wrong tool. Only the 14 patterns that LLD rounds actually use get a full lesson; the rest get one line each in the smell drills.
• Analogy, then mechanism, then trade-off. Depth sits in folded "Go deeper" sections.
• Step through every diagram. Diagrams with a step bar reveal one part at a time. Predict the next part before pressing Next.
• Real, tested code. Every Java file in this handbook was compiled with Java 17 and run; the output blocks are the real output. Code marked with a red dot is the version to avoid; green is the fix.
• Production notes. Green "In production" boxes show where the idea lives in the JDK, Spring, and payment systems, so the handbook serves your day job too.
• Interview signals. Purple boxes say what interviewers listen for at SDE-2 and what lifts an answer above the bar.
• Live tools. A pattern picker, an LRU simulator, a round timer, a mock rubric, and a machine coding starter project.

How to study one module

1. Clear the revision queue above at the start of each session: redo those problems from a blank page.
2. For each lesson: answer the "Try it first" question, read the short part, step through the figure, then read the code and type it out once. Typing, not pasting, is how the shapes get into your hands for the machine coding round.
3. Say it out loud: what problem the idea solves, and when it is the wrong choice.
4. Do the self-check quiz at the end, then tick lessons as studied.
5. Tick the mastery checklist only when each item is true with your notes closed.

How to practice a problem

1. Pick the round format and start the timer on the interview playbook: 45 to 60 minutes for an LLD discussion (requirements, class diagram, key flows, key code), 90 to 120 minutes for machine coding (code that runs).
2. Then open the problem and compare section by section. Answer each guided deep dive before revealing it.
3. Set an honest status at the top of the problem page. The handbook schedules a review.
4. Redo it from memory when it comes due, faster each time. Then try the practice prompts in the tracker that use the same ideas.

Statuses and the revision queue

When a problem comes up for review, redo it without notes, then set the new status or press "Reviewed, same status" to restart its timer.

Where your progress is saved

Lesson ticks, mastery checks, readiness checks, and problem statuses save automatically to your account, privately: nobody else who opens this page sees them, and they follow you to other devices. The indicator in the top bar shows where the latest change went. If the page cannot reach your account (for example in a private window), it saves in this browser instead, and the tracker has a backup and restore box.

Scope

This handbook covers what SDE-2 LLD and machine coding rounds test, in the depth they test it: object-oriented modeling, UML that interviewers read, SOLID, 14 design patterns, state machines, concurrency inside one process, the tables and REST APIs that LLD rounds ask for, scoping a one-line prompt, and the craft of writing a runnable, extensible solution in 90 minutes. Code is Java 17; everything also runs on Java 21.

It deliberately leaves out: distributed systems (the HLD handbook covers them), framework internals beyond where a pattern appears, and the rarely used Gang of Four patterns beyond a one-line description. If an interviewer asks about one of those, the smell drills page gives you the sentence you need.

The map

Priority overview

Total: about 26 hours of study, plus about 35 hours for the 17 problems (60 to 120 minutes to attempt each, then 30 to 45 minutes to compare and note what you missed).

Short on time

With two weeks or less before an interview, take the fast track and come back for the rest later:

1. Module 2 (diagrams), Module 6, Module 7: the patterns that carry most answers.
2. Module 8 and Module 10: the method and the coding craft.
3. Module 9: at least locks, ConcurrentHashMap, and lock ordering.
4. Problems P1, P3, P6, P9, P10, P15, timed.
5. The interview playbook and three scoping drills, with two full mocks scored on the rubric.
6. Module 11 if your target companies ask for tables or API design in LLD rounds.

How each module is organized

• Lessons, each opening with a "Try it first" question, then the pressure the idea relieves, an analogy, the mechanism, code (red dot: avoid; green dot: prefer), and the trade-offs.
• Figures that step through one part at a time.
• Go deeper folds for details you need only sometimes.
• In production notes and Interview signal notes.
• Common mistakes, a self-check quiz, and a mastery checklist.

Problems follow one format: try it first; requirements with assumed answers and invariants; entities and responsibilities; class diagram; key flows; tested code with its real output; concurrency; guided deep dives; a minute-by-minute machine coding plan; what a strong answer shows; and follow-up questions.

Interviews test LLD in two formats, and this handbook prepares you for both:

Four qualities sit behind every rubric:

• Correct: the rules hold in every path, including errors and concurrent callers.
• Clear: names and responsibilities that a reader understands without you explaining.
• Changeable: the likely next requirement fits by adding a class, not by editing ten.
• Simple: no pattern or interface that does not pay for itself today or for the next obvious change.

A class is a blueprint; an object is one instance of it at runtime. Every object has three things:

• State: the values of its fields right now.
• Behavior: its methods, which read and change that state.
• Identity: it is distinguishable from other objects, even ones with equal state. Two tickets for the same car at the same time are still two tickets.

Objects with identity that matters over time are entities (an order, an account, a ticket). Objects defined only by their values are value objects (money, a date range, a coordinate); lesson 1.7 covers them.

class ParkingTicket {
    // what it knows (state)
    private final String id;            // identity: two tickets with equal fields are still different tickets
    private final String vehicleNumber;
    private final String spotId;
    private final Instant entryTime;
    private Instant exitTime;           // null while the vehicle is inside

    ParkingTicket(String id, String vehicleNumber, String spotId, Instant entryTime) {
        this.id = id;
        this.vehicleNumber = vehicleNumber;
        this.spotId = spotId;
        this.entryTime = entryTime;
    }

    // what it does (behavior that uses its own data)
    void close(Instant at) {
        if (exitTime != null) throw new IllegalStateException("ticket " + id + " already closed");
        if (at.isBefore(entryTime)) throw new IllegalArgumentException("exit before entry");
        exitTime = at;
    }

    Duration parkedFor(Instant now) {
        return Duration.between(entryTime, exitTime != null ? exitTime : now);
    }

    boolean isOpen() { return exitTime == null; }
    String id() { return id; }
}

The rule of thumb that drives most LLD decisions: put behavior with the data it needs. The ticket checks "closed twice" and "exit before entry" because it owns the times. If a service did these checks instead, every service that closes tickets would need to repeat them.

An invariant is a rule that must always hold for an object, such as "balance is never negative" or "a closed ticket has an exit time". Encapsulation keeps the data private and exposes only methods that preserve the invariants. It is not "add a getter and setter for every field": a public setter is a public field with extra typing.

class WalletBad {
    public BigDecimal balance = BigDecimal.ZERO;     // anyone can write anything
    public List<String> history = new ArrayList<>(); // anyone can clear it
}

class PaymentServiceBad {
    void pay(WalletBad w, BigDecimal amount) {
        // the rule "no negative balance" lives here, and in every other service that touches balance
        if (w.balance.compareTo(amount) >= 0) {
            w.balance = w.balance.subtract(amount);
            w.history.add("debit " + amount);
        }
    }
}

class Wallet {
    private BigDecimal balance = BigDecimal.ZERO;
    private final List<String> history = new ArrayList<>();

    void credit(BigDecimal amount) {
        requirePositive(amount);
        balance = balance.add(amount);
        history.add("credit " + amount);
    }

    void debit(BigDecimal amount) {
        requirePositive(amount);
        if (balance.compareTo(amount) < 0) {
            throw new IllegalStateException("insufficient balance: " + balance + " < " + amount);
        }
        balance = balance.subtract(amount);
        history.add("debit " + amount);
    }

    BigDecimal balance() { return balance; }                                // BigDecimal is immutable: safe to return
    List<String> history() { return Collections.unmodifiableList(history); } // read-only view, not the list itself

    private static void requirePositive(BigDecimal amount) {
        if (amount == null || amount.signum() <= 0) throw new IllegalArgumentException("amount must be positive");
    }
}

class Demo {
    public static void main(String[] args) {
        Wallet w = new Wallet();
        w.credit(new BigDecimal("500.00"));
        w.debit(new BigDecimal("120.50"));
        try { w.debit(new BigDecimal("1000")); throw new AssertionError(); } catch (IllegalStateException e) { System.out.println(e.getMessage()); }
        try { w.history().clear(); throw new AssertionError(); } catch (UnsupportedOperationException e) { System.out.println("history is read-only"); }
        System.out.println("balance " + w.balance() + ", history " + w.history());
        WalletBad b = new WalletBad();
        b.balance = new BigDecimal("-999");  // compiles, and the object cannot stop it
        new PaymentServiceBad().pay(b, BigDecimal.ONE);
        assert b.balance.signum() < 0;
    }
}

insufficient balance: 379.50 < 1000
history is read-only
balance 379.50, history [credit 500.00, debit 120.50]

What changed:

• Methods are named by intent (credit, debit), not by field (setBalance). Each one checks its rule and updates state and history together.
• Getters do not leak mutable internals. history() returns a read-only view. Returning the list itself would let callers clear it.
• Invalid states are impossible from outside. No caller, present or future, can make the balance negative.

An interface states what a component does; a class decides how. Code that depends on interfaces can work with any implementation: the real provider, a second provider, or a fake in tests.

interface PaymentGateway {
    PaymentResult charge(String orderId, BigDecimal amount);
}

record PaymentResult(boolean success, String reference) {}

class RazorpayGateway implements PaymentGateway {
    public PaymentResult charge(String orderId, BigDecimal amount) {
        // call the provider's API here
        return new PaymentResult(true, "rzp_" + orderId);
    }
}

class StripeGateway implements PaymentGateway {
    public PaymentResult charge(String orderId, BigDecimal amount) {
        return new PaymentResult(true, "pi_" + orderId);
    }
}

class OrderService {
    private final PaymentGateway gateway;   // depends on the contract, not on a vendor

    OrderService(PaymentGateway gateway) {  // the caller (or Spring) decides which one
        this.gateway = gateway;
    }

    String placeOrder(String orderId, BigDecimal amount) {
        PaymentResult r = gateway.charge(orderId, amount);
        if (!r.success()) throw new IllegalStateException("payment failed for " + orderId);
        return r.reference();
    }
}

class FakeGateway implements PaymentGateway {
    final List<String> charged = new ArrayList<>();
    public PaymentResult charge(String orderId, BigDecimal amount) {
        charged.add(orderId + ":" + amount);
        return new PaymentResult(true, "fake_" + orderId);
    }
}
// in a unit test: no network, and you can assert what was charged
// FakeGateway fake = new FakeGateway();
// new OrderService(fake).placeOrder("o1", new BigDecimal("99.00"));
// assertEquals(List.of("o1:99.00"), fake.charged);

Passing the dependency in through the constructor is dependency injection. Spring does it for you with @Service classes and constructor parameters, which is why Spring code is easy to test when it depends on interfaces.

Interface or abstract class?

Default to interfaces. Add an abstract class beneath an interface only when several implementations repeat the same fields and code.

Inheritance (extends) says "is a" and reuses the parent's code. Composition says "has a": an object holds other objects and delegates work to them. Inheritance is the tighter of the two, and the coupling shows up in three ways:

• Fragile base class. A subclass depends on how the parent is implemented, not just on what it promises. Parent changes can silently break it.
• Combination explosion. Independent variations multiply subclasses, as in the exporter example.
• Single slot. A Java class has one parent, so using it for code reuse spends it.

The classic proof of the fragile base class comes from Effective Java. A set that counts additions overrides both add and addAll:

// Count how many elements were ever added (Effective Java, Item 18)
class InstrumentedHashSet<E> extends HashSet<E> {
    int addCount = 0;

    @Override public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    @Override public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);   // HashSet.addAll calls add() for each element: counted twice
    }
}

HashSet.addAll happens to call add for each element, an implementation detail the subclass cannot see. The composed version holds a Set and forwards to it, so the inner set's internal calls never reach our counter:

class InstrumentedSet<E> {
    private final Set<E> inner;   // has-a: any Set implementation works
    private int addCount = 0;

    InstrumentedSet(Set<E> inner) { this.inner = inner; }

    boolean add(E e) {
        addCount++;
        return inner.add(e);
    }

    boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return inner.addAll(c);   // inner calls its own add(), not ours: counted once
    }

    int addCount() { return addCount; }
    boolean contains(Object o) { return inner.contains(o); }
}

class Demo {
    public static void main(String[] args) {
        InstrumentedHashSet<String> a = new InstrumentedHashSet<>();
        a.addAll(List.of("x", "y", "z"));
        InstrumentedSet<String> b = new InstrumentedSet<>(new HashSet<>());
        b.addAll(List.of("x", "y", "z"));
        System.out.println("inheritance: addCount = " + a.addCount + " (expected 3)");
        System.out.println("composition: addCount = " + b.addCount());
        assert a.addCount == 6 && b.addCount() == 3;
    }
}

inheritance: addCount = 6 (expected 3)
composition: addCount = 3

When inheritance is the right tool:

• A true is-a relationship where every subclass can stand in for the parent everywhere (Module 3, Liskov).
• A parent designed for extension: documented hooks, a fixed skeleton (template method, Module 6), usually abstract.
• Types that share an interface and real state, such as abstract class Account with SavingsAccount and CurrentAccount.

enum VehicleType { CAR, BIKE, TRUCK }

class FeeCalculatorBad {
    BigDecimal hourlyRate(VehicleType type) {
        switch (type) {                       // the same switch also lives in SpotFinder and Report
            case CAR:   return new BigDecimal("40");
            case BIKE:  return new BigDecimal("20");
            case TRUCK: return new BigDecimal("100");
            default:    throw new IllegalArgumentException("unknown type " + type);
        }
    }
}

Polymorphism means one call, many behaviors: vehicle.hourlyRate() runs the method of the object's runtime class (dynamic dispatch). Behavior that varies by type moves into the types, and callers stop caring which type they have.

interface Vehicle {
    BigDecimal hourlyRate();
    SpotSize spotSize();
}

enum SpotSize { SMALL, MEDIUM, LARGE }

class Car implements Vehicle {
    public BigDecimal hourlyRate() { return new BigDecimal("40"); }
    public SpotSize spotSize() { return SpotSize.MEDIUM; }
}

class Bike implements Vehicle {
    public BigDecimal hourlyRate() { return new BigDecimal("20"); }
    public SpotSize spotSize() { return SpotSize.SMALL; }
}

// a new type is a new class; no existing switch changes
class ElectricCar implements Vehicle {
    public BigDecimal hourlyRate() { return new BigDecimal("30"); }
    public SpotSize spotSize() { return SpotSize.MEDIUM; }
}

class FeeCalculator {
    BigDecimal fee(Vehicle v, long hours) {
        return v.hourlyRate().multiply(BigDecimal.valueOf(hours));   // dynamic dispatch picks the right rate
    }
}

Polymorphism is not the only fix. When the varying behavior is a policy that changes independently of the type (weekend pricing, festival discounts), put it in a strategy object instead (Module 6). Rule of thumb: what a thing is belongs in its class; how the business treats it belongs in a strategy.

Overriding vs overloading

Overriding (same signature in a subclass) is resolved at runtime by the object's class. Overloading (same name, different parameter types) is resolved at compile time by the declared type of the argument. This catches people in interviews:

class Printer {
    String describe(Object o) { return "object"; }
    String describe(String s) { return "string"; }
}

Printer p = new Printer();
Object o = "hello";            // static type Object, runtime type String
System.out.println(p.describe(o));         // prints "object": overloads are chosen at compile time
System.out.println(p.describe("hello"));   // prints "string"

Always put @Override on overriding methods. If the signature does not actually override (a typo, a different parameter type), the compiler then refuses it instead of quietly creating an overload.

A value object is defined entirely by its values: two Money objects with 10.00 INR are interchangeable. Good value objects are:

• Immutable: no setters; operations return new objects. They are safe to share, cache, use as map keys, and pass between threads.
• Valid at construction: the constructor rejects bad input, so an invalid instance can never exist.
• Equal by value: equals and hashCode are based on the fields. A Java record generates both, plus accessors.

record Money(BigDecimal amount, Currency currency) {
    Money {                                         // compact constructor: validate and normalize once
        Objects.requireNonNull(amount);
        Objects.requireNonNull(currency);
        // INR has 2 fraction digits; 10.005 is rejected instead of silently rounded
        amount = amount.setScale(currency.getDefaultFractionDigits(), RoundingMode.UNNECESSARY);
    }

    static Money of(String amount, String currency) {
        return new Money(new BigDecimal(amount), Currency.getInstance(currency));
    }

    Money plus(Money other) {
        requireSameCurrency(other);
        return new Money(amount.add(other.amount), currency);   // a new object; this one never changes
    }

    Money minus(Money other) {
        requireSameCurrency(other);
        return new Money(amount.subtract(other.amount), currency);
    }

    boolean isNegative() { return amount.signum() < 0; }

    private void requireSameCurrency(Money other) {
        if (!currency.equals(other.currency)) throw new IllegalArgumentException("currency mismatch");
    }
}

Money a = Money.of("10.5", "INR");                 // stored as 10.50
Money b = Money.of("10.50", "INR");
System.out.println(a.equals(b) + " " + (a.hashCode() == b.hashCode()));   // true true
System.out.println(new BigDecimal("10.5").equals(new BigDecimal("10.50"))); // false: scale differs
System.out.println(0.1 + 0.2);                                             // 0.30000000000000004

class MutablePoint {
    int x, y;
    MutablePoint(int x, int y) { this.x = x; this.y = y; }
    @Override public boolean equals(Object o) {
        return o instanceof MutablePoint p && p.x == x && p.y == y;
    }
    @Override public int hashCode() { return Objects.hash(x, y); }
}

class Demo {
    public static void main(String[] args) {

// ... (code shown above) ...

        assert a.equals(b);
        try { Money.of("10.005", "INR"); throw new AssertionError(); } catch (ArithmeticException e) { System.out.println("10.005 INR rejected"); }
        System.out.println(a.plus(b) + " " + a.minus(b).minus(b).isNegative());
        Map<MutablePoint, String> owners = new HashMap<>();
        MutablePoint p = new MutablePoint(1, 2);
        owners.put(p, "alice");
        p.x = 5;                                    // mutate a key after insertion
        System.out.println(owners.get(p));          // null: the entry sits in the bucket for the old hash
        System.out.println(owners.containsKey(new MutablePoint(1, 2)));   // false: equals now fails
        assert owners.get(p) == null;
    }
}

true true
false
0.30000000000000004
10.005 INR rejected
Money[amount=21.00, currency=INR] true
null
false

Two details in that code matter in fintech interviews:

• BigDecimal.equals compares scale: 10.5 and 10.50 are not equal, but compareTo returns 0. Normalizing the scale in the constructor makes record equality behave. Many payment systems avoid the issue by storing amounts as a long count of minor units (paise or cents).
• Rounding is a business decision. RoundingMode.UNNECESSARY makes an impossible amount fail loudly. When rounding is needed (splitting 100 into 3), choose the mode deliberately and decide where the leftover paisa goes (Problem 7).

And the reason keys must be immutable:

class MutablePoint {
    int x, y;
    MutablePoint(int x, int y) { this.x = x; this.y = y; }
    @Override public boolean equals(Object o) {
        return o instanceof MutablePoint p && p.x == x && p.y == y;
    }
    @Override public int hashCode() { return Objects.hash(x, y); }
}

Map<MutablePoint, String> owners = new HashMap<>();
MutablePoint p = new MutablePoint(1, 2);
owners.put(p, "alice");
p.x = 5;                                    // mutate a key after insertion
System.out.println(owners.get(p));          // null: the entry sits in the bucket for the old hash
System.out.println(owners.containsKey(new MutablePoint(1, 2)));   // false: equals now fails

What to draw in each round:

Conventions worth knowing:

• Stereotypes go above the name in double angle brackets: <<interface>>, <<abstract>>, <<enum>> (formal UML prints each pair as one guillemet character). On a whiteboard, writing "interface" above the name is enough.
• Abstract classes and methods are italic. On a whiteboard, write "abstract".
• Enums list their constants in the field compartment.
• Omit getters, setters, constructors, and toString. Show the methods that carry the design's rules.

Two distinctions trip people up:

• Association vs dependency is about time. If the reference is stored in a field, it is an association. If it only appears in a method signature or body, it is a dependency.
• Composition vs aggregation is about ownership. If the whole creates the part, nobody else holds it, and deleting the whole deletes the part, it is composition. If parts are passed in and can outlive or be shared, it is aggregation.

Multiplicity says how many instances take part, written at the far end of the line:

Navigability is shown with an open arrowhead: the arrow points to the class that is known. Customer --> Order means a customer can reach its orders; an order does not hold its customer object. Choose the direction from the use cases: "list a customer's orders" needs Customer -> Order or a repository query.

Two modeling rules that save trouble:

• Prefer one-way references. Two-way references must be kept in sync by every method that changes them.
• Reference by ID across independent entities. A Payment stores orderId, not an Order object. Inside one whole (an order and its lines), hold objects. This is the same boundary a database or a microservice split would draw later.

Every relationship becomes a specific code shape. Interviewers often check that your diagram and your code agree.

// Composition: the order creates and owns its lines; a line never exists without its order
class Order {
    private final String id;
    private final List<OrderLine> lines = new ArrayList<>();

    Order(String id) { this.id = id; }

    void addLine(String sku, int qty) {
        lines.add(new OrderLine(sku, qty));        // created here, never handed in from outside
    }

    List<OrderLine> lines() { return Collections.unmodifiableList(lines); }
}

record OrderLine(String sku, int qty) {}

// Aggregation: the team holds players that exist on their own and may join other teams
class Team {
    private final List<Player> players = new ArrayList<>();

    void add(Player p) { players.add(p); }        // received, not created
    int size() { return players.size(); }
}

class Player {
    final String name;
    Player(String name) { this.name = name; }
}

// Association: a long-lived reference held in a field
class Invoice {
    private final Customer billedTo;               // Invoice --> Customer
    Invoice(Customer billedTo) { this.billedTo = billedTo; }
    String customerName() { return billedTo.name(); }
}

record Customer(String name) {}

// Dependency: used briefly, as a parameter or local variable, then forgotten
class InvoicePrinter {
    String print(Invoice invoice) {                // InvoicePrinter ..> Invoice
        return "Invoice for " + invoice.customerName();
    }
}

// Inheritance (generalization) and realization (implements)
interface Shape { double area(); }                 // Circle ..|> Shape (realization)

abstract class Account {                           // SavingsAccount --|> Account (generalization)
    protected long balancePaise;
}

class SavingsAccount extends Account {}
class Circle implements Shape {
    private final double r;
    Circle(double r) { this.r = r; }
    public double area() { return Math.PI * r * r; }
}

A sequence diagram shows one scenario over time: participants across the top, time flowing down, one arrow per call.

Conventions:

• Solid arrow with a filled head: a call. Dashed arrow: a return value.
• Self-call: an arrow that loops back to the same lifeline.
• Notes or frames mark loops (loop), options (opt), and alternatives (alt). A note is enough on a whiteboard.
• Keep it to one scenario and 5-10 messages. A sequence diagram that shows every branch is unreadable.

A sequence diagram is the quickest way to check your class diagram: every arrow needs a method on the receiving class, and every object on top needs a way to reach the next one.

A state diagram shows the states one object can be in and the events that move it between them. Write transitions as event [guard] / action: the event triggers, the guard must be true, the action runs.

The diagram is also the spec for the code. Module 7 turns diagrams like this into an enum with a transition table, or into the State pattern when each state carries real behavior.

How to measure coupling in practice: count how many classes a typical change touches, and how many imports and constructor parameters a class has. More than five or six collaborators in a constructor is usually a cohesion problem in that class.

A class should have one reason to change. Robert Martin's sharper version: a module should be responsible to one actor, one group of people who request its changes. "One responsibility" does not mean "one method"; it means one owner.

class InvoiceService {
    private final Map<String, String> db = new HashMap<>();

    BigDecimal total(List<LineItem> items) {             // changes when finance changes tax rules
        BigDecimal sub = items.stream().map(LineItem::amount).reduce(BigDecimal.ZERO, BigDecimal::add);
        return sub.multiply(new BigDecimal("1.18")).setScale(2, RoundingMode.HALF_UP);
    }

    String render(String id, List<LineItem> items) {      // changes when the layout changes
        return "INVOICE " + id + "\n" + items.size() + " items, total " + total(items);
    }

    void save(String id, List<LineItem> items) {          // changes when storage changes
        db.put(id, render(id, items));
    }
}

class TaxCalculator {                                     // owner: finance rules
    private final BigDecimal rate;
    TaxCalculator(BigDecimal rate) { this.rate = rate; }

    BigDecimal total(List<LineItem> items) {
        BigDecimal sub = items.stream().map(LineItem::amount).reduce(BigDecimal.ZERO, BigDecimal::add);
        return sub.add(sub.multiply(rate)).setScale(2, RoundingMode.HALF_UP);
    }
}

class InvoiceRenderer {                                   // owner: presentation
    String render(String id, List<LineItem> items, BigDecimal total) {
        return "INVOICE " + id + "\n" + items.size() + " items, total " + total;
    }
}

interface InvoiceRepository {                             // owner: storage
    void save(String id, String document);
}

class InvoiceService2 {                                   // coordinates; holds no rules of its own
    private final TaxCalculator tax;
    private final InvoiceRenderer renderer;
    private final InvoiceRepository repo;

    InvoiceService2(TaxCalculator tax, InvoiceRenderer renderer, InvoiceRepository repo) {
        this.tax = tax; this.renderer = renderer; this.repo = repo;
    }

    String issue(String id, List<LineItem> items) {
        String doc = renderer.render(id, items, tax.total(items));
        repo.save(id, doc);
        return doc;
    }
}

record LineItem(String name, BigDecimal price, int qty) {
    BigDecimal amount() { return price.multiply(BigDecimal.valueOf(qty)); }
}

// ... (code shown above) ...

class Demo {
    public static void main(String[] args) {
        List<LineItem> items = List.of(new LineItem("pen", new BigDecimal("10.00"), 3), new LineItem("book", new BigDecimal("250.00"), 1));
        List<String> saved = new ArrayList<>();
        String doc = new InvoiceService2(new TaxCalculator(new BigDecimal("0.18")), new InvoiceRenderer(), (id, d) -> saved.add(id)).issue("INV-7", items);
        System.out.println(doc);
        assert doc.endsWith("330.40") && saved.equals(List.of("INV-7"));
        InvoiceService bad = new InvoiceService();
        assert bad.total(items).equals(new BigDecimal("330.40"));
        bad.save("x", items);
    }
}

INVOICE INV-7
2 items, total 330.40

Software entities should be open for extension, closed for modification. Adding behavior should mean adding code, not editing code that already works.

class DiscountServiceBad {
    BigDecimal discount(String customerType, BigDecimal amount) {
        if (customerType.equals("REGULAR")) return BigDecimal.ZERO;
        if (customerType.equals("PREMIUM")) return amount.multiply(new BigDecimal("0.10"));
        if (customerType.equals("EMPLOYEE")) return amount.multiply(new BigDecimal("0.30"));
        // every new customer type edits this method, and its tests
        throw new IllegalArgumentException(customerType);
    }
}

interface DiscountPolicy {
    BigDecimal discount(BigDecimal amount);
}

class NoDiscount implements DiscountPolicy {
    public BigDecimal discount(BigDecimal amount) { return BigDecimal.ZERO; }
}

class PercentOff implements DiscountPolicy {
    private final BigDecimal percent;
    PercentOff(String percent) { this.percent = new BigDecimal(percent); }
    public BigDecimal discount(BigDecimal amount) {
        return amount.multiply(percent).divide(BigDecimal.valueOf(100), 2, RoundingMode.HALF_UP);
    }
}

class DiscountService {
    private final Map<String, DiscountPolicy> policies;   // built once, at startup

    DiscountService(Map<String, DiscountPolicy> policies) { this.policies = policies; }

    BigDecimal discount(String customerType, BigDecimal amount) {
        DiscountPolicy p = policies.get(customerType);
        if (p == null) throw new IllegalArgumentException("no policy for " + customerType);
        return p.discount(amount);
    }
}

DiscountService service = new DiscountService(Map.of(
        "REGULAR", new NoDiscount(),
        "PREMIUM", new PercentOff("10"),
        "EMPLOYEE", new PercentOff("30"),
        "STUDENT", new PercentOff("15")));   // new type: one line of wiring, no edits to the service

class Demo {
    public static void main(String[] args) {

// ... (code shown above) ...

        BigDecimal d = service.discount("STUDENT", new BigDecimal("200.00"));
        System.out.println("student discount on 200.00 = " + d);
        assert d.compareTo(new BigDecimal("30.00")) == 0;
        assert new DiscountServiceBad().discount("PREMIUM", new BigDecimal("100")).compareTo(BigDecimal.TEN) == 0;
    }
}

student discount on 200.00 = 30.00

The pattern behind this fix is strategy plus a factory (Module 6). The switch does not disappear; it moves to one place where the objects are created, which is where variation belongs.

Objects of a subtype must be usable anywhere the parent type is expected, without surprises (Barbara Liskov, 1987). In practice a subclass must not:

• Demand more from callers (stronger preconditions, such as "amount must be under 1,000").
• Promise less (weaker postconditions, such as "balance may not decrease").
• Throw exceptions the parent's contract does not allow, or break the parent's invariants.

class Account {
    protected long balance;
    Account(long balance) { this.balance = balance; }

    void withdraw(long amount) {
        if (amount > balance) throw new IllegalStateException("insufficient funds");
        balance -= amount;
    }
    long balance() { return balance; }
}

class FixedDepositAccount extends Account {
    FixedDepositAccount(long balance) { super(balance); }

    @Override void withdraw(long amount) {
        throw new UnsupportedOperationException("no withdrawals before maturity");   // breaks the parent's promise
    }
}

class BillPayer {
    void payFrom(List<Account> accounts, long amount) {
        for (Account a : accounts) {
            if (a.balance() >= amount) { a.withdraw(amount); return; }   // explodes on a fixed deposit
        }
    }
}

interface Withdrawable {                               // a capability, not every account has it
    long balance();
    void withdraw(long amount);
}

abstract class BankAccount {
    protected long balance;
    BankAccount(long balance) { this.balance = balance; }
    public long balance() { return balance; }
}

class SavingsAccount extends BankAccount implements Withdrawable {
    SavingsAccount(long balance) { super(balance); }
    public void withdraw(long amount) {
        if (amount > balance) throw new IllegalStateException("insufficient funds");
        balance -= amount;
    }
}

class FixedDeposit extends BankAccount {               // simply has no withdraw method
    FixedDeposit(long balance) { super(balance); }
}

class BillPayer2 {
    void payFrom(List<? extends Withdrawable> accounts, long amount) {   // the type says what it needs
        for (Withdrawable a : accounts) {
            if (a.balance() >= amount) { a.withdraw(amount); return; }
        }
        throw new IllegalStateException("no account can pay " + amount);
    }
}

class Demo {
    public static void main(String[] args) {
        try {
            new BillPayer().payFrom(List.of(new FixedDepositAccount(10_000), new Account(5_000)), 1_000);
            throw new AssertionError();
        } catch (UnsupportedOperationException e) {
            System.out.println("bad design: " + e.getMessage());
        }
        SavingsAccount s = new SavingsAccount(5_000);
        new BillPayer2().payFrom(List.of(s), 1_000);
        System.out.println("good design: savings balance " + s.balance());
        assert s.balance() == 4_000;
    }
}

bad design: no withdrawals before maturity
good design: savings balance 4000

The textbook example is Square extends Rectangle: setting a square's width must also change its height, which breaks code that sets width and height independently. The lesson is the same: "a square is a rectangle" is true in geometry and false for a mutable Rectangle class. Is-a must hold for behavior, not just for the English sentence.

Clients should not be forced to depend on methods they do not use. Prefer several small role interfaces over one large one.

interface PaymentProvider {
    String charge(String customer, long amountPaise);
    void refund(String chargeId, long amountPaise);
    String createSubscription(String customer, String plan);
    void cancelSubscription(String subscriptionId);
}

class CashOnDelivery implements PaymentProvider {
    public String charge(String customer, long amountPaise) { return "cod-" + customer; }
    public void refund(String chargeId, long amountPaise) { throw new UnsupportedOperationException(); }
    public String createSubscription(String c, String p) { throw new UnsupportedOperationException(); }
    public void cancelSubscription(String s) { throw new UnsupportedOperationException(); }
}

interface Chargeable { String charge(String customer, long amountPaise); }
interface Refundable { void refund(String chargeId, long amountPaise); }
interface SubscriptionCapable {
    String createSubscription(String customer, String plan);
    void cancelSubscription(String subscriptionId);
}

class CardProvider implements Chargeable, Refundable, SubscriptionCapable {
    public String charge(String customer, long amountPaise) { return "card-" + customer; }
    public void refund(String chargeId, long amountPaise) { /* call the card network */ }
    public String createSubscription(String customer, String plan) { return "sub-" + plan; }
    public void cancelSubscription(String subscriptionId) { }
}

class CashOnDelivery2 implements Chargeable {           // implements only what it can do
    public String charge(String customer, long amountPaise) { return "cod-" + customer; }
}

class RefundService {
    private final Refundable provider;                   // depends only on the role it uses
    RefundService(Refundable provider) { this.provider = provider; }
    void refund(String chargeId, long amount) { provider.refund(chargeId, amount); }
}