solid-principles

v2026.09.24

SOLID design principles. Covers SRP, OCP, LSP, ISP, DIP. Use when designing classes and modules. USE WHEN: user mentions "SOLID", "single responsibility", "open closed", "Liskov", "interface segregation", "dependency inversion", "dependency injection", asks about "class design", "OOP principles", "extensibility", "abstraction", "how to design classes" DO NOT USE FOR: General code quality - use `clean-code` instead, Specific patterns - use design patterns skills, Language-specific OOP - use framework-specific skills

GitHub
安装命令
npx skhub add claude-dev-suite/solid-principles
Markdown
SKILL.md

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-PatternViolated PrincipleSolution
God ClassSRPSplit into focused classes with single responsibility
Switch on TypeOCPUse polymorphism and strategy pattern
Throwing in SubclassLSPEnsure subclasses honor base class contract
Fat InterfaceISPSplit into smaller, role-specific interfaces
new Keyword EverywhereDIPUse dependency injection, depend on abstractions
Fragile Base ClassLSP, OCPPrefer composition over inheritance
Marker InterfaceISPUse proper abstractions with meaningful methods

Quick Troubleshooting

IssuePrincipleFix
Class changing for multiple reasonsSRPExtract separate classes for each responsibility
Must modify class to add featureOCPMake class extensible via interfaces/abstractions
Subclass breaks parent's testsLSPEnsure subclass can substitute parent without issues
Implementing empty methodsISPSplit interface into smaller, focused interfaces
Hard to test due to concrete depsDIPInject dependencies through interfaces
Can't swap implementationsDIPDepend 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

Reference Documentation

发现
标签

此技能尚未发布标签。

版本
最新版本元数据

版本

v2026.09.24

发布时间

Sep 24, 2026

分类

未分类

许可证

MIT

源路径

skills/best-practices/solid-principles

默认分支

main

最新提交

9496306

Tree SHA

fe4e2f1