SOLID Principles

Deep Knowledge: Use mcp__documentation__fetch_docs with technology: solid-principles for comprehensive documentation.

When NOT to Use This Skill

This skill focuses on OOP design principles. Do NOT use for:

• Functional programming - SOLID is primarily for OOP, use FP-specific patterns instead

• Simple scripts/utilities - SOLID adds complexity; use for larger systems

• Performance-critical code - Abstraction overhead may impact performance

• General code quality - Use clean-code skill for naming, functions, readability

Anti-Patterns

Anti-Pattern Violated Principle Solution

God Class SRP Split into focused classes with single responsibility

Switch on Type OCP Use polymorphism and strategy pattern

Throwing in Subclass LSP Ensure subclasses honor base class contract

Fat Interface ISP Split into smaller, role-specific interfaces

new Keyword Everywhere DIP Use dependency injection, depend on abstractions

Fragile Base Class LSP, OCP Prefer composition over inheritance

Marker Interface ISP Use proper abstractions with meaningful methods

Quick Troubleshooting

Issue Principle Fix

Class changing for multiple reasons SRP Extract separate classes for each responsibility

Must modify class to add feature OCP Make class extensible via interfaces/abstractions

Subclass breaks parent's tests LSP Ensure subclass can substitute parent without issues

Implementing empty methods ISP Split interface into smaller, focused interfaces

Hard to test due to concrete deps DIP Inject dependencies through interfaces

Can't swap implementations DIP Depend on abstractions, not concretions

S - Single Responsibility

// ❌ Bad - Multiple responsibilities class User { save() { /* database logic / } sendEmail() { / email logic / } generateReport() { / report logic */ } }

// ✅ Good - Single responsibility each class User { /* user data only */ } class UserRepository { save(user: User) { } } class EmailService { send(to: string, message: string) { } } class ReportGenerator { generate(user: User) { } }

O - Open/Closed

// ❌ Bad - Modify class to add new payment class PaymentProcessor { process(payment: Payment) { if (payment.type === 'credit') { /* ... / } else if (payment.type === 'paypal') { / ... */ } // Must modify to add new type } }

// ✅ Good - Extend without modification interface PaymentMethod { process(amount: number): Promise<void>; }

class CreditCardPayment implements PaymentMethod { } class PayPalPayment implements PaymentMethod { } class CryptoPayment implements PaymentMethod { } // New, no changes needed

L - Liskov Substitution

// ❌ Bad - Square can't substitute Rectangle class Rectangle { setWidth(w: number) { this.width = w; } setHeight(h: number) { this.height = h; } } class Square extends Rectangle { setWidth(w: number) { this.width = this.height = w; } // Breaks expectation }

// ✅ Good - Use composition or separate abstractions interface Shape { getArea(): number; } class Rectangle implements Shape { } class Square implements Shape { }

I - Interface Segregation

// ❌ Bad - Fat interface interface Worker { work(): void; eat(): void; sleep(): void; } class Robot implements Worker { eat() { throw new Error('Robots dont eat'); } // Forced to implement }

// ✅ Good - Segregated interfaces interface Workable { work(): void; } interface Eatable { eat(): void; } interface Sleepable { sleep(): void; }

class Human implements Workable, Eatable, Sleepable { } class Robot implements Workable { }

D - Dependency Inversion

// ❌ Bad - High-level depends on low-level class UserService { private db = new MySQLDatabase(); // Concrete dependency }

// ✅ Good - Depend on abstractions interface Database { query(sql: string): Promise<any>; }

class UserService { constructor(private db: Database) { } // Injected abstraction }

// Can use any implementation new UserService(new MySQLDatabase()); new UserService(new PostgresDatabase()); new UserService(new MockDatabase()); // For testing

Authoritative Sources

• SOLID Principles by Robert C. Martin - https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html

• Agile Software Development by Robert C. Martin - https://www.oreilly.com/library/view/agile-software-development/0135974445/

Reference Documentation

• Clean Code

• Design Patterns

• Quality Principles (Consolidated)