SOLID Principles in TypeScript

Five principles of object-oriented design (Robert C. Martin) that keep code flexible, testable, and resistant to rot — adapted to idiomatic TypeScript, where interfaces, structural typing, union types, and plain functions often satisfy a principle without ceremony.

🎯 Why: Design for Change

The goal of writing software is to be able to change it safely. SOLID is the OO toolkit for that goal: SRP limits what changes when a reason to change appears, OCP lets you extend without editing tested code, LSP keeps substitutions safe, ISP keeps consumers from breaking on unrelated changes, DIP lets you swap implementations without rewriting policy. Every rule below earns its keep only if it shrinks the next diff.

How to use this skill

1. Match the symptom in the decision guide below to a principle.
2. Open references/principles.md for the full before/after TypeScript example and the "when this is over-engineering" note for that principle.
3. Apply the smallest change that removes the actual pain. SOLID is a response to demonstrated change pressure, not a checklist to apply preemptively. A 30-line app does not need an interface per class.

Reference file

• references/principles.md — all five principles (SRP, OCP, LSP, ISP, DIP) with motivation, a bad example, a refactor, TypeScript-specific notes, and when not to apply each.

The five principles

Decision guide — symptom → principle

TypeScript-specific guidance

• Interfaces are free and structural. You don't need a class to implement an interface explicitly — any object with the right shape satisfies it. This makes ISP and DIP cheap.
• Prefer narrow function types over fat interfaces. A dependency that is "something that can save(user)" can be (user: User) => Promise<void>, not a Repository interface — that is ISP and DIP in one move.
• Union types + exhaustive switch is a valid OCP alternative. When the set of variants is closed and known, a discriminated union with a never-checked switch is often clearer than a class hierarchy.
• Constructor injection is the default DIP mechanism. Pass collaborators in; let a composition root wire concretions. Avoid new-ing dependencies inside business logic.
• Don't abstract on speculation. Introduce an interface when you have a second implementation or a real testing need — not "just in case."