📐 SOLID Principles

SOLID = Five design principles for better code

S - Single Responsibility Principle
O - Open/Closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

Goal: Maintainable, flexible, understandable code.

A class should have only ONE reason to change.

Bad: UserManager
  - Saves to database
  - Sends emails
  - Validates input
  - Generates reports

Good:
  - UserRepository (database)
  - EmailService (emails)
  - UserValidator (validation)
  - ReportGenerator (reports)

✓ Easier to understand
✓ Easier to test
✓ Easier to change
✓ Fewer surprises when modifying

Software entities should be:
  - Open for EXTENSION
  - Closed for MODIFICATION

Add new behavior by adding NEW code.
Don't change existing, working code.

Bad: Modifying existing code for each new shape

if shape.type == "circle":
    area = π * r²
elif shape.type == "square":
    area = s²
elif shape.type == "triangle":  ← Must modify!
    area = ...

Good: Extend with new classes

Shape (interface) → getArea()
Circle extends Shape
Square extends Shape
Triangle extends Shape  ← Just add new class!

✓ New features don't break old code
✓ Reduced regression risk
✓ Easier maintenance

Subtypes must be substitutable for their base types.

If you use Parent class, any Child should work.
Child shouldn't surprise you with different behavior.

Bad: Subclass breaks expectations

class Rectangle:
    setWidth(w)
    setHeight(h)

class Square extends Rectangle:
    setWidth(w):
        width = w
        height = w  ← Surprise! Also changes height?!

User expects rectangle behavior, gets square behavior.

Good: Don't inherit if contract differs.

✗ Overriding method to throw exception
✗ Overriding method to do nothing
✗ Subclass adds restrictions parent didn't have
✗ Client needs to check which type it actually is

Clients shouldn't depend on interfaces they don't use.

Many small, specific interfaces
Better than one large, general interface.

Bad: Fat interface

interface Worker:
    work()
    eat()
    sleep()

Robot implements Worker:
    work() ✓
    eat() → What?! Robots don't eat!
    sleep() → Robots don't sleep!

Good: Segregated interfaces

interface Workable:
    work()

interface Eatable:
    eat()

interface Sleepable:
    sleep()

Human implements Workable, Eatable, Sleepable
Robot implements Workable

✓ Classes only implement what they need
✓ Smaller, focused interfaces
✓ Easier to understand and maintain

High-level modules shouldn't depend on low-level modules.
Both should depend on abstractions.

Abstractions shouldn't depend on details.
Details should depend on abstractions.

Bad: Direct dependency

class OrderService:
    def __init__(self):
        self.database = PostgresDatabase()  ← Concrete!
        self.emailer = GmailSender()        ← Concrete!

Can't change database without changing OrderService.

Good: Depend on abstractions

class OrderService:
    def __init__(self, database: Database, emailer: EmailService):
        self.database = database
        self.emailer = emailer

Inject any implementation!
PostgresDatabase or MongoDatabase
GmailSender or SendGridSender

✓ Easy to swap implementations
✓ Easy to test (inject mocks)
✓ Decoupled modules
✓ Flexible architecture

One class does everything.
Violates: Single Responsibility

Fix: Split into focused classes.

switch (object.type):
    case A: doA()
    case B: doB()
    case C: doC()

Violates: Open/Closed

Fix: Polymorphism. Each type implements behavior.

Square extends Rectangle but breaks width/height independence.

Violates: Liskov Substitution

Fix: Separate hierarchy or immutable shapes.

interface DoEverything:
    method1(), method2(), ... method50()

Violates: Interface Segregation

Fix: Split into focused interfaces.

class Service:
    def __init__(self):
        self.dep = ConcreteDependency()  ← Creating internally

Violates: Dependency Inversion

Fix: Inject dependencies through constructor.

✓ Long-lived applications
✓ Growing codebases
✓ Team development
✓ Need for testing
✓ Changing requirements

✗ Scripts and one-offs
✗ Very small programs
✗ Throwaway code
✗ Performance-critical hot paths