solid-principles

SOLID の原則

深い知識：包括的なドキュメントについては、テクノロジーに solid-principles を指定して mcp__documentation__fetch_docs を使用してください。

このスキルを使用しない場合

このスキルでは、オブジェクト指向プログラミングの設計原則を扱います。次の場合には使用しないでください。

• 関数型プログラミング - SOLID は主にオブジェクト指向プログラミング向けです。代わりに、関数型プログラミングに特化したパターンを使用してください
• 単純なスクリプト／ユーティリティ - SOLID を適用すると複雑になるため、大規模なシステムで使用してください
• パフォーマンスが重要なコード - 抽象化によるオーバーヘッドがパフォーマンスに影響する場合があります
• 一般的なコード品質 - 命名、関数、可読性については clean-code スキルを使用してください

アンチパターン

アンチパターン	違反する原則	解決策
God Class	SRP	単一の責任を持つ、役割を絞ったクラスに分割する
Switch on Type	OCP	ポリモーフィズムとストラテジーパターンを使用する
Throwing in Subclass	LSP	サブクラスが基底クラスの契約を守るようにする
Fat Interface	ISP	インターフェースを、役割に特化した小さなものに分割する
new Keyword Everywhere	DIP	依存性注入を使用し、抽象に依存する
Fragile Base Class	LSP, OCP	継承よりコンポジションを優先する
Marker Interface	ISP	意味のあるメソッドを備えた適切な抽象を使用する

よくある問題の解決方法

問題	原則	対処方法
複数の理由でクラスが変更される	SRP	責任ごとにクラスを分離する
機能の追加にクラスの変更が必要	OCP	インターフェース／抽象化を通じてクラスを拡張できるようにする
サブクラスによって親クラスのテストが失敗する	LSP	サブクラスが問題なく親クラスを置き換えられるようにする
空のメソッドを実装している	ISP	インターフェースを、役割を絞った小さなものに分割する
具象的な依存関係のためテストが難しい	DIP	インターフェースを通じて依存関係を注入する
実装を切り替えられない	DIP	具象ではなく、抽象に依存する

S - 単一責任の原則

// ❌ 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 - オープン・クローズドの原則

// ❌ 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 - リスコフの置換原則

// ❌ 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 - インターフェース分離の原則

// ❌ 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 - 依存性逆転の原則

// ❌ 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

信頼できる情報源

• Robert C. Martin 著「SOLID Principles」 - https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html
• Robert C. Martin 著「Agile Software Development」 - https://www.oreilly.com/library/view/agile-software-development/0135974445/

参考ドキュメント

• クリーンコード
• デザインパターン
• 品質原則（統合版）