solid

# SOLID Principles ## Overview SOLID is a mnemonic for five object-oriented design principles introduced by Robert C. Martin. Together they guide developers toward code that is easier to understand, more flexible to change, and simpler to test. | Letter | Principle | One-Line Summary | |--------|-----------|------------------| | **S** | Single Responsibility | A class should have only one reason to change. | | **O** | Open/Closed | Open for extension, closed for modification. | | **L** | Liskov Substitution | Subtypes must be substitutable for their base types. | | **I** | Interface Segregation | No client should be forced to depend on methods it does not use. | | **D** | Dependency Inversion | Depend on abstractions, not concretions. | --- ## S — Single Responsibility Principle (SRP) > "A class should have one, and only one, reason to change." — Robert C. Martin A "reason to change" maps to a **stakeholder** or **actor**. If two different actors can request changes to the same class, that class has more than one responsibility. ### Violation ```typescript class UserService { createUser(name: string, email: string): User { // validate input if (!email.includes("@")) throw new Error("Invalid email"); // persist to database const user = this.db.query( "INSERT INTO users (name, email) VALUES ($1, $2) RETURNING *", [name, email] ); // send welcome email this.emailClient.send({ to: email, subject: "Welcome!", body: `Hello ${name}, welcome aboard.`, }); // write audit log this.logger.info(`User created: ${email}`); return user; } } ``` This class has **four reasons to change**: validation rules, database schema, email template, and logging format. ### Corrected ```typescript class UserValidator { validate(name: string, email: string): void { if (!email.includes("@")) throw new InvalidEmailError(email); } } class UserRepository { save(name: string, email: string): Promise<User> { return this.db.query( "INSERT INTO users (name, email) VALUES ($1, $2) RETURNING *", [name, email] ); } } class WelcomeEmailSender { send(user: User): Promise<void> { return this.emailClient.send({ to: user.email, subject: "Welcome!", body: `Hello ${user.name}, welcome aboard.`, }); } } class CreateUserUseCase { constructor( private validator: UserValidator, private repo: UserRepository, private welcomeEmail: WelcomeEmailSender, private logger: Logger ) {} async execute(name: string, email: string): Promise<User> { this.validator.validate(name, email); const user = await this.repo.save(name, email); await this.welcomeEmail.send(user); this.logger.info(`User created: ${email}`); return user; } } ``` Each class now has one reason to change, and `CreateUserUseCase` orchestrates them. --- ## O — Open/Closed Principle (OCP) > "Software entities should be open for extension, but closed for modification." — Bertrand Meyer You should be able to add new behavior **without modifying existing code**. This is typically achieved through abstraction and polymorphism. ### Violation ```typescript class DiscountCalculator { calculate(order: Order): number { switch (order.customerType) { case "regular": return 0; case "premium": return order.total * 0.1; case "vip": return order.total * 0.2; default: return 0; } } } // Adding a new customer type requires modifying this class. ``` ### Corrected ```typescript interface DiscountStrategy { calculate(order: Order): number; } class RegularDiscount implements DiscountStrategy { calculate(order: Order): number { return 0; } } class PremiumDiscount implements DiscountStrategy { calculate(order: Order): number { return order.total * 0.1; } } class VipDiscount implements DiscountStrategy { calculate(order: Order): number { return order.total * 0.2; } } class DiscountCalculator { constructor(private strategy: DiscountStrategy) {} calculate(order: Order): number { return this.strategy.calculate(order); } } // Adding a new customer type = adding a new class. No existing code changes. class EmployeeDiscount implements DiscountStrategy { calculate(order: Order): number { return order.total * 0.3; } } ``` --- ## L — Liskov Substitution Principle (LSP) > "Objects of a superclass should be replaceable with objects of a subclass without breaking the program." — Barbara Liskov If `S` is a subtype of `T`, then objects of type `T` may be replaced with objects of type `S` without altering the correctness of the program. Subtypes must honor the behavioral contract of the base type. ### Violation ```typescript class Rectangle { constructor(protected width: number, protected height: number) {} setWidth(w: number): void { this.width = w; } setHeight(h: number): void { this.height = h; } area(): number { return this.width * this.height; } } class Square extends Rectangle { setWidth(w: number): void { this.width = w; this.height = w; // violates Rectangle's contract } setHeight(h: number): void { this.width = h; this.height = h; // violates Rectangle's contract } } // Client code that breaks with Square: function assertAreaCorrect(rect: Rectangle): void { rect.setWidth(5); rect.setHeight(4); console.assert(rect.area() === 20); // Fails for Square! area() returns 16 } ``` ### Corrected ```typescript interface Shape { area(): number; } class Rectangle implements Shape { constructor(private width: number, private height: number) {} area(): number { return this.width * this.height; } } class Square implements Shape { constructor(private side: number) {} area(): number { return this.side * this.side; } } // Both satisfy the Shape contract. No inheritance relationship forces // Square to pretend it is a Rectangle. function printArea(shape: Shape): void { console.log(`Area: ${shape.area()}`); } ``` ### LSP Rules of Thumb - **Preconditions** cannot be strengthened in a subtype. - **Postconditions** cannot be weakened in a subtype. - **Invariants** of the base type must be preserved by the subtype. - The **history constraint**: a subtype should not introduce state changes the base type would not allow. --- ## I — Interface Segregation Principle (ISP) > "No client should be forced to depend on methods it does not use." — Robert C. Martin Large, "fat" interfaces force implementing classes to provide stub methods for features they do not support. Split interfaces along client boundaries. ### Violation ```typescript interface Printer { print(doc: Document): void; scan(doc: Document): void; fax(doc: Document): void; staple(doc: Document): void; } class SimplePrinter implements Printer { print(doc: Document): void { /* works */ } scan(doc: Document): void { throw new Error("Not supported"); } fax(doc: Document): void { throw new Error("Not supported"); } staple(doc: Document): void { throw new Error("Not supported"); } } ``` `SimplePrinter` is forced to know about scanning, faxing, and stapling even though it supports none of them. ### Corrected ```typescript interface Printable { print(doc: Document): void; } interface Scannable { scan(doc: Document): void; } interface Faxable { fax(doc: Document): void; } interface Stapleable { staple(doc: Document): void; } class SimplePrinter implements Printable { print(doc: Document): void { /* works */ } } class MultiFunctionPrinter implements Printable, Scannable, Faxable { print(doc: Document): void { /* works */ } scan(doc: Document): void { /* works */ } fax(doc: Document): void { /* works */ } } ``` Each client depends only on the interface it actually uses. --- ## D — Dependency Inversion Principle (DIP) > "High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions." — Robert C. Martin ### Violation ```typescript class MySqlDatabase { save(data: Record<string, unknown>): void { // MySQL-specific implementation } } class OrderService { private db = new MySqlDatabase(); // direct dependency on a concrete class createOrder(order: Order): void { this.db.save(order.toRecord()); } } // Changing from MySQL to PostgreSQL requires modifying OrderService. ``` ### Corrected ```typescript // Abstraction — defined in the high-level module interface OrderRepository { save(order: Order): Promise<void>; } // Detail — depends on the abstraction class MySqlOrderRepository implements OrderRepository { async save(order: Order): Promise<void> { // MySQL-specific implementation } } class PostgresOrderRepository implements OrderRepository { async save(order: Order): Promise<void> { // PostgreSQL-specific implementation } } // High-level module — depends on the abstraction class OrderService { constructor(private repo: OrderRepository) {} async createOrder(order: Order): Promise<void> { await this.repo.save(order); } } // Composition root — wiring const service = new OrderService(new PostgresOrderRepository()); ``` The high-level policy (`OrderService`) and the low-level detail (`PostgresOrderRepository`) both depend on the abstraction (`OrderRepository`). The dependency is **inverted**. --- ## How SOLID Relates to Other Concepts ### SOLID and Clean Architecture Clean Architecture is the architectural expression of SOLID at the system level: | SOLID Principle | Clean Architecture Manifestation | |----------------|----------------------------------| | SRP | Each layer has a single reason to change (UI, business rules, data). | | OCP | New features are added by creating new Use Cases, not modifying existing ones. | | LSP | Interface Adapters can be swapped (PostgreSQL for MySQL) without breaking Use Cases. | | ISP | Ports (interfaces) are defined per use case, not as monolithic repository interfaces. | | DIP | The Dependency Rule — inner layers define interfaces, outer layers implement them. | ### SOLID and Design Patterns Many GoF design patterns exist specifically to satisfy SOLID: | Pattern | Primary SOLID Principle | |---------|------------------------| | Strategy | OCP, DIP | | Observer | OCP, DIP | | Decorator | OCP, SRP | | Factory Method / Abstract Factory | DIP | | Adapter | ISP, DIP | | Command | SRP, OCP | | Template Method | OCP, LSP | ### SOLID and Testability Each SOLID principle directly improves testability: | Principle | Testing Benefit | |-----------|----------------| | SRP | Smaller classes with fewer dependencies = simpler test setup. | | OCP | New behavior tested in isolation via new classes, existing tests remain green. | | LSP | Test doubles (mocks, stubs) can replace real implementations safely. | | ISP | Narrow interfaces require fewer mock methods. | | DIP | Dependencies are injected, making them trivially replaceable with test doubles. | ## Common Pitfalls | Pitfall | Description | |---------|-------------| | Over-engineering with SRP | Splitting every method into its own class creates an explosion of trivial types. SRP means one *reason to change*, not one *method*. | | Premature abstraction for OCP | Do not create Strategy/Plugin architectures for code that has only one variant. Wait for the second use case. | | Ignoring LSP in collections | A `ReadOnlyList` that extends `List` and throws on `add()` violates LSP. | | Interface explosion with ISP | Do not create a one-method interface for every single method. Group by **client need**. | | DIP everywhere | Not every dependency needs an interface. Stable, unlikely-to-change dependencies (e.g., standard library) can be referenced directly. | ## Best Practices - Apply SOLID principles as guardrails during code review, not as upfront design mandates. - When you feel friction adding a feature, check which SOLID principle is being violated. - Use constructor injection as the default mechanism for DIP — it makes dependencies explicit and immutable. - Write tests first (TDD) — SOLID violations surface quickly when code is hard to test. - Balance SOLID with YAGNI: do not add abstractions speculatively. Introduce them when the second variation appears. - Review class names regularly — if a class name contains "And" or "Manager" or "Service" doing too many things, SRP is likely violated.