Design patterns and SOLID: the must-knows

For this sheet, we'll go principle by principle, then pattern by pattern, with the smallest Java that shows each one and the follow-up question an interviewer asks next. The first half is the core you can't skip (SOLID, singletons, factories, builders, the structural wrappers). The second half covers behavioural patterns, the JDK map, anti-patterns, and how to put it all together in a parking-lot-style LLD round.

01Picture it first: from problem to pattern

Many candidates memorise patterns as a list of 23 names. That's backwards. Interviewers give you a problem ("pricing differs by vehicle type and changes every quarter"), and you're expected to recognise which force is at play and reach for the matching pattern. If you can read the map below left to right, you can handle most design follow-ups.

The diagram groups the common problems by what varies, and points each one at the pattern that isolates that variation.

Fig. 1

A pattern picker: on the left, problems grouped as creation, wrapping and behaviour; on the right, the pattern that solves each, such as many optional fields leading to builder, incompatible interface leading to adapter, add behaviour by wrapping leading to decorator, swappable algorithm leading to strategy and lifecycle rules leading to state

Notice the shape of the map. Every arrow starts with something that varies or something you want to hide. If you can't name that thing in your design, you don't need the pattern yet.

02SOLID, one principle at a time

SOLID is five principles collected by Robert C. Martin. Interviewers rarely want the acronym recited; they want a small violation, the fix, and why the fix is cheaper to change. Here's the can't-skip list, then code for the ones people fumble.

• S, Single Responsibility: a class should have one reason to change, meaning one actor or stakeholder who asks for changes. "Does one thing" is a weaker reading; the useful test is "who would file the ticket that changes this class?"
• O, Open/Closed: open for extension, closed for modification. Adding a new payment type should mean adding a class, not editing a switch in five places.
• L, Liskov Substitution: any subtype must work wherever the parent is expected, honouring its contract: no stronger preconditions, no weaker postconditions, no new surprise exceptions, invariants preserved.
• I, Interface Segregation: clients shouldn't depend on methods they don't use. Prefer several role interfaces (Readable, Writable) over one fat one.
• D, Dependency Inversion: high-level policy depends on abstractions it owns, and low-level details implement them. OrderService depends on OrderRepository, and the MySQL class implements it.

SRP: the invoice that does everything

This class has three reasons to change: finance changes the tax rule, design changes the PDF, and ops changes the mail provider.

// Violation: three actors, one class
class InvoiceService {
    Money total(Invoice inv) { /* tax rules */ }
    byte[] renderPdf(Invoice inv) { /* layout */ }
    void email(Invoice inv, String to) { /* SMTP */ }
}

// Fix: one reason to change each, composed by a thin coordinator
class InvoiceCalculator { Money total(Invoice inv) { /* tax rules */ } }
class InvoiceRenderer   { byte[] pdf(Invoice inv) { /* layout */ } }
class InvoiceMailer     { void send(byte[] pdf, String to) { /* SMTP */ } }

The fix isn't "more classes is better". It's that a tax change now can't break PDF rendering, and each piece gets a focused test.

OCP: the switch that grows forever

The classic violation is a switch on a type code that every new feature edits. The fix moves each case into its own class behind an interface, so new behaviour is new code.

// Violation: every new method edits this switch
double fee(String method, double amount) {
    return switch (method) {
        case "CARD" -> amount * 0.02;
        case "UPI"  -> 0;
        default     -> throw new IllegalArgumentException(method);
    };
}

// Fix: extend by adding an implementation
interface FeePolicy { double fee(double amount); }
record CardFee() implements FeePolicy { public double fee(double a) { return a * 0.02; } }
record UpiFee()  implements FeePolicy { public double fee(double a) { return 0; } }

Interview questions for this topicComing soon