SOLID — Notes

Why it matters

SOLID is the canonical sanity check for OO designs. It doesn't guarantee good design — but its violations are reliable red flags.

Per-principle gotchas

• SRP: "responsibility" = axis of change. A User class that handles persistence and password hashing has two axes of change (DB schema vs auth policy).
• OCP: hardest to apply preemptively. Apply it when you've actually seen the second variation, not the first.
• LSP: contracts cover pre/post-conditions, invariants, and exceptions — not just method signatures. The classic counterexample: a Square extending Rectangle breaks the post-condition "setWidth doesn't change height".
• ISP: in Go-style languages, interfaces are implicit and small by convention. In Java/C#, do it explicitly.
• DIP: pair with DI. Dependencies passed in via constructor / setters / framework — never new inside business logic.

SOLID vs other acronyms

Acronym	Stands for	Focus
SOLID	five OO principles	class-level design
DRY	Don't Repeat Yourself	duplication
KISS	Keep It Simple, Stupid	over-engineering
YAGNI	You Aren't Gonna Need It	speculative features
CUPID	Composable, Unix-philosophy, Predictable, Idiomatic, Domain-based	systems-oriented alternative to SOLID

Refs

• Robert C. Martin: "Clean Architecture" (2017) — full SOLID treatment.
• Uncle Bob's original 2002 papers on each principle.
• Dan North: "CUPID — for joyful coding" (2022) — alternative framing.