solid-principles

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)