Imagine this: I'm in the middle of a super intense interview for a sick engineering role. Things are going great. I'm casually dropping architectures and AI pipelines. Then, out of nowhere, the interviewer drops the most basic, classic question of all time:

"Can you explain the SOLID principles to me?"

Brain. Freeze. 🧊

I literally use these principles intuitively every single day, but suddenly, trying to put them into words felt like explaining how to ride a bike to an alien. I stumbled, mixed up Liskov with Interface Segregation, and basically made a total fool of myself.

So, I'm tossing this cheat sheet into my notebook so I never get caught lacking again, and hopefully hide my pain in a fun little cheat sheet for any junior engineers (or embarrassed seniors) out there!

1. Single Responsibility (SRP)

The Rule: A class should do exactly one thing. It should only have one reason to change.

Imagine you have an employee at a restaurant. If that employee is cooking the food, taking the orders, and doing the taxes, they are going to do a terrible job at all three. Your code is the same.

// ❌ Bad: The "Do It All" Class
class UserManager {
  createUser(data) { /* DB logic */ }
  sendWelcomeEmail(user) { /* SMTP logic */ }
}

// ✅ Good: Split the jobs!
class UserRepository {
  createUser(data) { /* DB logic only */ }
}

class EmailService {
  sendWelcomeEmail(user) { /* SMTP logic only */ }
}

2. Open-Closed (OCP)

The Rule: Open for extension, closed for modification.

Think of your code like a smartphone. When you want new features, you don't open up the hardware and solder new chips (modification). You just download a new App (extension)!

// ❌ Bad: Every new shape breaks the class!
class AreaCalculator {
  calculate(shape) {
    if (shape.type === 'circle') return Math.PI * shape.r ** 2;
    if (shape.type === 'square') return shape.side ** 2;
    // adding a triangle means editing this file! :(
  }
}

Instead, let the shapes calculate their own areas by implementing a common interface. The calculator just calls shape.getArea() unconditionally.

// ✅ Good: Open for extension!
class AreaCalculator {
  // Can sum areas of ANY shapes without modifying this method!
  calculateTotal(shapes) {
    return shapes.reduce((total, shape) => total + shape.getArea(), 0);
  }
}

class Circle {
  constructor(r) { this.r = r; }
  getArea() { return Math.PI * this.r ** 2; }
}

class Square {
  constructor(side) { this.side = side; }
  getArea() { return this.side ** 2; } // Adding this doesn't break Calculator!
}

3. Liskov Substitution (LSP)

The Rule: If it looks like a duck and quacks like a duck, but needs batteries, you have the wrong abstraction!

More formally: If class B inherits from class A, you should be able to pass B into anything that expects A without breaking the app.

class Bird { fly() { ... } }

// ❌ Bad: Penguins can't fly!
class Penguin extends Bird {
  fly() { throw new Error("I swim, bro!"); }
}

If a piece of code loops through a list of Birds and calls fly(), the Penguin breaks the app. The fix? Create a narrower base class, or interfaces like IFlyable and ISwimmable.

// ✅ Good: Proper abstractions
interface IFlyable { fly(); }
interface ISwimmable { swim(); }

class Duck implements IFlyable, ISwimmable {
  fly() { ... }
  swim() { ... }
}

class Penguin implements ISwimmable {
  swim() { ... }
}

4. Interface Segregation (ISP)

The Rule: Don't force clients to depend on methods they don't use.

Imagine going to a restaurant and the waiter hands you a 500-page book that contains the menu, the staff payroll, and the restaurant's blueprint. You just want the menu!

// ❌ Bad: The "God" Interface
interface SmartDevice {
  print();
  fax();
  scan();
}

Break it down into IPrinter, IFax, and IScanner. A basic printer only implements IPrinter, keeping things neat.

// ✅ Good: Segregated Interfaces
interface IPrinter { print(); }
interface IScanner { scan(); }

class BasicPrinter implements IPrinter {
  print() { console.log("Printing!"); } 
  // Doesn't need to fake a fax method!
}

5. Dependency Inversion (DIP)

The Rule: Rely on abstractions (interfaces), not concrete implementations (classes).

If you hardcode an MySQLDatabase inside your API service, you are glued to MySQL. If your boss asks to switch to MongoDB tomorrow, you'll be crying in the bathroom.

// ❌ Bad: Tightly coupled
class PaymentService {
  constructor() {
    this.db = new MySQLDatabase(); // Glued!
  }
}

// ✅ Good: Depending on an abstraction
class PaymentService {
  constructor(databaseInterface) {
    this.db = databaseInterface;
  }
}

By injecting an interface, you can pass in a mock database during testing, or swap the entire database engine without touching the PaymentService logic.

Conclusion

And there you have it! Next time I'm in an interview and they ask about SOLID, I won't freeze. I'll just picture penguins breaking apps and waitresses handing out blueprints. Hope this helps you too!