SOLID Principles¶

Prerequisites: OOP Fundamentals

← OOP Fundamentals | Next: Design Patterns →

Why This Exists¶

SOLID is five letters candidates can recite and almost never apply under pressure. The reason: each principle sounds like a rule about code style, when it's actually a rule about where the pain shows up when a requirement changes. Learn them as "what breaks and why," not as definitions, and you'll recognize a violation while you're writing the code instead of after the interviewer asks "what if we add a new payment type?"

S — Single Responsibility Principle¶

A class should have one reason to change. Not "one method" — one axis of change.

# Violation: Ticket owns pricing AND printing AND persistence
class Ticket:
    def calculate_fee(self) -> float: ...
    def print_receipt(self) -> None: ...
    def save_to_database(self) -> None: ...

A pricing-model change, a receipt-format change, and a storage-engine swap are three unrelated reasons this one class gets edited — and three unrelated teams stepping on the same file.

class Ticket:
    def calculate_fee(self) -> float: ...

class ReceiptPrinter:
    def print(self, ticket: Ticket) -> None: ...

class TicketRepository:
    def save(self, ticket: Ticket) -> None: ...

O — Open/Closed Principle¶

Open for extension, closed for modification: adding new behavior should mean adding a class, not editing an existing, already-tested one.

# Violation: every new payment type means editing this method
def process_payment(method: str, amount: float) -> bool:
    if method == "credit_card":
        return charge_credit_card(amount)
    elif method == "upi":
        return charge_upi(amount)
    elif method == "wallet":       # <- added today, and this whole function was re-tested
        return charge_wallet(amount)

class PaymentMethod(ABC):
    @abstractmethod
    def pay(self, amount: float) -> bool: ...

class WalletPayment(PaymentMethod):     # new file, zero edits elsewhere
    def pay(self, amount: float) -> bool:
        return charge_wallet(amount)

def process_payment(method: PaymentMethod, amount: float) -> bool:
    return method.pay(amount)           # never changes again

This is the payoff of polymorphism — OCP is what you get when abstraction is done right at the seam that actually varies.

L — Liskov Substitution Principle¶

Any subtype must be usable anywhere the supertype is expected, without the caller needing to know which one it got, and without breaking the caller's expectations.

# Violation: Square silently breaks Rectangle's contract
class Rectangle:
    def set_width(self, w): self.width = w
    def set_height(self, h): self.height = h
    def area(self): return self.width * self.height

class Square(Rectangle):
    def set_width(self, w):
        self.width = self.height = w        # side-effects the caller didn't ask for
    def set_height(self, h):
        self.width = self.height = h

def resize(rect: Rectangle):
    rect.set_width(5)
    rect.set_height(4)
    assert rect.area() == 20   # passes for Rectangle, FAILS for Square (area == 16)

Square is-a rectangle geometrically, but it is not substitutable for Rectangle in code that assumes width and height vary independently — the inheritance is a lie at the behavioral level, even though it looks correct at the type level.

I — Interface Segregation Principle¶

No client should be forced to depend on methods it doesn't use. A fat interface with ten methods forces every implementer to stub out the seven it doesn't need.

# Violation: every worker must implement every method, even irrelevant ones
class Worker(ABC):
    @abstractmethod
    def work(self): ...
    @abstractmethod
    def eat(self): ...
    @abstractmethod
    def sleep(self): ...

class RobotWorker(Worker):
    def work(self): ...
    def eat(self): raise NotImplementedError   # a robot doesn't eat — forced stub
    def sleep(self): raise NotImplementedError

class Workable(ABC):
    @abstractmethod
    def work(self): ...

class Eater(ABC):
    @abstractmethod
    def eat(self): ...

class RobotWorker(Workable):        # only implements what it actually does
    def work(self): ...

Any class implementing a method with raise NotImplementedError or a no-op stub is telling you the interface it's implementing was too fat.

D — Dependency Inversion Principle¶

High-level modules should depend on abstractions, not on concrete low-level modules — and the concrete implementation should be injected in, not constructed inside.

# Violation: ParkingLot is hard-wired to one specific notifier
class ParkingLot:
    def __init__(self):
        self.notifier = EmailNotifier()   # concrete dependency, buried inside

    def notify_full(self):
        self.notifier.send("Lot is full")

class Notifier(ABC):
    @abstractmethod
    def send(self, message: str) -> None: ...

class ParkingLot:
    def __init__(self, notifier: Notifier):     # dependency injected, not constructed
        self.notifier = notifier

    def notify_full(self):
        self.notifier.send("Lot is full")

# test code can inject a FakeNotifier; production injects SmsNotifier — ParkingLot never changes

This is dependency injection — the mechanism, not a separate principle. DIP says depend on abstractions; DI is how you actually wire the concrete instance in, usually via the constructor. It's also why the class becomes trivially testable: swap in a test double without touching ParkingLot at all.

Interfaces vs. Abstract Classes¶

Rule of thumb: if you're tempted to write class Foo(Bar, Baz) with two abstract classes, at least one of them should probably be an interface instead.

Class Relationships (UML Basics)¶

classDiagram
    class Vehicle {
        <<abstract>>
        +license_plate: str
        +spot_size_required()* str
    }
    class Car
    class ParkingLot {
        +spots: List~ParkingSpot~
        +park(vehicle) Ticket
    }
    class ParkingSpot {
        +is_free() bool
    }
    class Ticket
    class Engine

    Vehicle <|-- Car : inheritance (is-a)
    ParkingLot *-- ParkingSpot : composition (owns, dies with parent)
    ParkingLot o-- Ticket : aggregation (references, outlives parent)
    Car *-- Engine : composition
    ParkingLot ..> Vehicle : dependency (uses in a method signature)

Getting composition vs. aggregation right matters for one concrete reason: it answers "if I delete the parent, does the child still exist?" — for a ParkingLot and its ParkingSpots, no. For a ParkingLot and Tickets it issued, yes (the ticket is handed to the customer and outlives the parking session).

Trade-offs¶

Interview Questions¶

Key Takeaways¶

Previous: OOP Fundamentals | Next: Design Patterns