SOLID Principles — Interactive OOP

Explore Topics

🧭

Introduction

Why five principles — and why they stuck

🧪 SOLID Refactoring Lab — Five Letters, Five Defenses

🧭

Introduction

Why five principles — and why they stuck

In 2000, Robert C. Martin distilled a decade of object-oriented design wisdom into a short paper, "Design Principles and Design Patterns". Five of those principles — picked out and rearranged into a memorable acronym by Michael Feathers — became SOLID. The goal is narrow: produce code that many developers can collaboratively change without breaking each other's work. Every letter targets a different failure mode of object-oriented systems: tangled responsibilities, brittle conditionals, broken hierarchies, fat interfaces, and hardwired dependencies. Mastering SOLID is the bridge between knowing OO syntax and writing OO software that lives.

Key Ideas

Robert C. Martin — "Design Principles and Design Patterns" (Object Mentor, 2000)
Michael Feathers rearranged Martin's principles into the SOLID acronym
S = Single Responsibility · O = Open-Closed · L = Liskov Substitution
I = Interface Segregation · D = Dependency Inversion
All five operate at the CLASS level — they are not architecture rules
Goal: understandable, readable, testable code that teams can change in parallel

Strengths

✦Provides a shared vocabulary for code reviews and design discussions
✦Each principle has a single, memorable, transferable sentence
✦Maps cleanly to Java mechanisms (interface, abstract class, DI)
✦Catches design smells before they harden into legacy debt

Weaknesses

△Easy to over-apply — splitting too aggressively creates "lasagna code"
△Some principles (LSP, DIP) require runtime testing to verify, not just inspection
△No single principle is a complete answer; they only work together
△Critics argue the acronym is mnemonic, not rigorous

Used in:Every major OO codebase — Spring, the JDK itself, JUnit, IntelliJ plugins — leans on SOLID. The JDK's java.io role interfaces (Readable, Closeable, Flushable) are textbook ISP. Spring's constructor injection IS dependency inversion. When you can name the principle, you can name the rot.

Code Snippets

Quiz

Introduction Quiz

QUIZ 1/6

What is the primary goal Robert C. Martin attributed to the SOLID design principles?

Diagrams

SOLID Map — Each letter, each Java mechanism

Loading diagram...

DIP — Inverting the dependency arrow

Loading diagram...

SRP — Reasons to change, before & after

Loading diagram...

Practice

Drag each code smell into the SOLID letter it most directly violates.

EXERCISE 1/5

A class that calculates, persists, AND prints

A long if/else chain on a String "type" field

Square extends Rectangle; setWidth secretly changes height

Subclass overrides a method to throw UnsupportedOperationException

A Vehicle interface forcing every car to implement charge()

private final EmailSender e = new EmailSender(); inside a service

Employee class with logHours, requestTimeOff, calculateSalary, updateEmail

CdPlayer.stream(url) throwing because CDs cannot stream

SRP

OCP

LSP

ISP

DIP

Find the LSP violation

EXERCISE 2/5

Click on the line you think contains the bug, then press Confirm.

1abstract class Bird {

2 abstract void fly();

5class Sparrow extends Bird {

6 void fly() { System.out.println("flapping wings"); }

9class Penguin extends Bird {

10 void fly() {

11 throw new UnsupportedOperationException("penguins do not fly");

12 }

13}

15void migrate(List<Bird> flock) {

16 for (Bird b : flock) b.fly(); // boom when a Penguin is in flock

17}

Common SOLID misconceptions

EXERCISE 3/5

SRP means a class can only have one method.

OCP forbids bug fixes — once a class is closed, you can never edit it.

If Square IS-A Rectangle in geometry, then `class Square extends Rectangle` must satisfy LSP.

Throwing UnsupportedOperationException in a method is usually an ISP smell.

Dependency Inversion and Dependency Injection are the same thing.

You should refactor a legacy codebase to be fully SOLID-compliant in one sprint.

Refactor OrderService to satisfy DIP

EXERCISE 4/5

// ── Before: violates DIP ──
class OrderService {
    private final EmailSender mail = new EmailSender();
    void placeOrder(String item, String customer) {
        mail.send(customer, "Order placed: " + item);
    }
}

// ── After: satisfies DIP ──
 Notifier {
    void notify(String recipient, String message);
}

class EmailNotifier  Notifier {
    public void notify(String r, String m) { /* send email */ }
}

class OrderService {
    private final  notifier;

    OrderService( notifier) {
        this.notifier = ;
    }

    void placeOrder(String item, String customer) {
        notifier.notify(customer, "Order placed: " + item);
    }
}

Predict the LSP failure

EXERCISE 5/5

abstract class Account {
    final String id; double balance;
    Account(String id, double b) { this.id = id; balance = b; }
    abstract void withdraw(double amount);
}

class Savings extends Account {
    Savings(String id, double b) { super(id, b); }
    void withdraw(double a) { balance -= a; }
}

class FixedDeposit extends Account {
    FixedDeposit(String id, double b) { super(id, b); }
    void withdraw(double a) {
        throw new UnsupportedOperationException("locked");
    }
}

List<Account> accs = List.of(
    new Savings     ("S-1", 500),     // line A
    new FixedDeposit("F-1", 1000),    // line B
    new Savings     ("S-2", 200)      // line C
);
for (Account a : accs) {
    a.withdraw(50);
    System.out.println(a.id + " ok");
}

Statement 1 — first iteration (Savings S-1)

Statement 2 — second iteration (FixedDeposit F-1)

Statement 3 — third iteration (Savings S-2)