SOLID Principles Cheat Sheet

Explains the five SOLID object-oriented design principles with concrete before-and-after code examples for each one.

2 PagesIntermediateApr 2, 2026

The Five Principles

A one-line summary of each SOLID principle.

S - Single Responsibility- A class should have only one reason to change, i.e. one responsibility
O - Open/Closed- Software entities should be open for extension but closed for modification
L - Liskov Substitution- Subtypes must be substitutable for their base types without altering program correctness
I - Interface Segregation- Clients shouldn't be forced to depend on methods or interfaces they don't use
D - Dependency Inversion- High-level modules should depend on abstractions, not concrete low-level implementations

Single Responsibility

Splitting a class that has more than one reason to change.

java

// Violates SRP: handles both persistence and formattingclass Report {    void generate() { /* build report data */ }    void saveToFile(String path) { /* file I/O */ }    void printToConsole() { /* formatting + printing */ }}// Follows SRP: each class has one reason to changeclass Report {    void generate() { /* build report data */ }}class ReportSaver {    void saveToFile(Report report, String path) { /* file I/O */ }}class ReportPrinter {    void printToConsole(Report report) { /* formatting */ }}

Open/Closed & Dependency Inversion

Extending behavior through an abstraction instead of editing existing code.

java

interface PaymentMethod {    void pay(double amount);}class CreditCardPayment implements PaymentMethod {    public void pay(double amount) { /* charge card */ }}class PayPalPayment implements PaymentMethod {    public void pay(double amount) { /* charge PayPal */ }}// Adding a new payment method requires no changes to Checkoutclass Checkout {    private final PaymentMethod paymentMethod;    Checkout(PaymentMethod paymentMethod) {        this.paymentMethod = paymentMethod;    }    void completeOrder(double total) {        paymentMethod.pay(total);    }}

Liskov Substitution & Interface Segregation

A subtype that breaks its parent's contract, and a fat interface split apart.

java

// Violates LSP: Square changes Rectangle's expected behaviorclass Rectangle {    protected int width, height;    void setWidth(int w) { width = w; }    void setHeight(int h) { height = h; }    int area() { return width * height; }}class Square extends Rectangle {    void setWidth(int w) { width = height = w; }  // breaks Rectangle's contract    void setHeight(int h) { width = height = h; }}// Follows ISP: split a fat interface into focused onesinterface Printer { void print(Document d); }interface Scanner { void scan(Document d); }// SimplePrinter only implements Printer, not forced to implement scan()class SimplePrinter implements Printer {    public void print(Document d) { /* ... */ }}

Pro Tip

Treat SOLID as heuristics, not laws — over-applying Dependency Inversion or Interface Segregation to simple, stable code adds indirection without payoff. Apply them where change is actually expected.

Was this cheat sheet helpful?

Design Patterns (Gang of Four) Cheat Sheet

Algorithms & Big-O Cheat Sheet