solid-principles

SOLID Principles

Five principles for writing code that's easy to change.

---

S — Single Responsibility Principle

A class should have one reason to change.

One class doing two unrelated things = two reasons to change it.

# Violation: UserService handles auth AND notifications
class UserService:
    def login(self, email, password): ...
    def send_welcome_email(self, user): ...  # belongs elsewhere

# Better
class AuthService:
    def login(self, email, password): ...

class UserNotifier:
    def send_welcome(self, user): ...

Signal: method names have unrelated verbs; the class imports from many unrelated modules.

---

O — Open/Closed Principle

Open for extension, closed for modification.

Add behavior by adding code, not by editing existing code.

// Violation: every new payment method requires editing
function processPayment(type: string, amount: number) {
    if (type === 'card') { ... }
    if (type === 'crypto') { ... }  // keep adding ifs
}

// Better: polymorphism or strategy
interface PaymentProcessor {
    process(amount: number): Promise<void>;
}
class CardProcessor implements PaymentProcessor { ... }
class CryptoProcessor implements PaymentProcessor { ... }

Signal: feature additions require editing a switch/if-else chain in a stable class.

---

L — Liskov Substitution Principle

Subtypes must be substitutable for their supertypes.

If B extends A, code using A must work with B without knowing the difference.

# Violation: Square breaks Rectangle invariants
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 = w
        self.height = w  # breaks Rectangle callers who set W and H independently

Signal: overriding a method throws an exception, does nothing, or changes invariants the parent declares.