SOLID Principles

• SOLID = five class-design rules for easy-to-change code
• SRP, OCP, LSP, ISP, DIP
• Core goal: one requirement change touches one place
• Not a ripple across many classes

• Guidelines for managing change, not laws
• Apply when a real change pressure appears

• Why SOLID? Keeps change local and cheap
• Smell to principle? Giant class SRP, type if/else OCP, throwing subclass LSP, unused methods ISP, new deps DIP
• Overkill when? Stable code, one type, no second reason to change

• One reason to change = one actor owns the class
• Bad: Invoice has calculateTotal(), saveToDb(), printPdf()
• Tax, DB and layout changes all edit one class

• Open to extension, closed to modification
• Add behavior by adding code, not editing tested code
• Bad: area(shape) uses if/elif on type; every new shape edits it
• Fix: Shape interface with area(); each shape implements it

from abc import ABC, abstractmethod
class Shape(ABC):
    @abstractmethod
    def area(self): ...
class Circle(Shape):
    def area(self): return 3.14 * self.r ** 2

new shape = new class, no edits

• Reason to change? One actor's requirement: tax, DB, layout
• OCP vs SRP? OCP extends without editing; SRP gives one owner
• OCP pattern? Polymorphism / Strategy
• Premature when? One type, no new types expected

• LSP: a subtype works wherever its base type is expected
• No stronger preconditions (what callers must supply)
• No weaker postconditions (what callers get back)
• Keep every base invariant

• Square setters change both sides, so a Rectangle caller gets the wrong area
• Penguin.fly() throws: any caller holding a Penguin as a Bird crashes

• Detect a break? An override throws, or a base caller's expectation fails
• Why Square fails? It breaks Rect's invariant: width and height are independent
• Precondition? What callers must supply. Postcondition: what the method guarantees

• ISP: no client forced to depend on methods it does not use
• Prefer many small role interfaces
• Violation: Worker has work() and eat()
• Robot must no-op or throw in eat()
• Fix: split into Workable and Eatable

• DIP: high-level modules depend on abstractions
• Both high and low level depend on the interface
• Violation: OrderService runs self.db = MySQLDatabase()
• Cannot test or swap it
• Fix: Database interface, injected via constructor

class OrderService:
    def __init__(self, db: Database):
        self.db = db
svc = OrderService(FakeDatabase())

tests pass a fake

• ISP vs SRP? ISP: client's view of an interface; SRP: one reason to change
• DIP vs DI? Principle vs the technique that applies it
• DIP and unit tests? Inject a fake, no real DB

• Over-splitting: one-method classes hide the flow; split only on a real second reason to change
• One interface per class, one implementation, no test seam: noise, not DIP
• Type switch in one place, no new types expected: leave it (rule of three)

• Over-apply SOLID? Yes: no change pressure means only extra indirection
• Composition vs inheritance for LSP? Composition has no override to break
• Spot SRP issues? Manager/Util names, edits from several teams

• SRP: one reason to change = one actor
• OCP: extend by adding code, not editing
• LSP: keep the base contract
• ISP: small role interfaces
• DIP is the principle, DI the technique

class OrderService:
    def __init__(self, db: Database):
        self.db = db  # injected

DIP fix: inject, never MySQLDatabase()

• Recite: giant class, if/elif, throwing override, empty method, new
• Hardest? LSP, its contract is implicit
• Most overlap? SRP and ISP, both split by role