wasabeef デザインパターン提案と SOLID 原則評価
コードベースに適用可能なデザインパターンを提案し、SOLID 原則の遵守状況を評価します。
使い方
/design-patterns [分析対象] [オプション]
オプション
--suggest: 適用可能なパターンを提案 (デフォルト)--analyze: 既存パターンの使用状況を分析--refactor: リファクタリング案を生成--solid: SOLID 原則の遵守状況をチェック--anti-patterns: アンチパターンを検出
基本例
# プロジェクト全体のパターン分析
/design-patterns
# 特定ファイルへのパターン提案
/design-patterns src/services/user.js --suggest
# SOLID 原則チェック
/design-patterns --solid
# アンチパターン検出
/design-patterns --anti-patterns
分析カテゴリ
1. 生成に関するパターン
- Factory Pattern: オブジェクト生成の抽象化
- Builder Pattern: 複雑なオブジェクトの段階的構築
- Singleton Pattern: インスタンスの一意性保証
- Prototype Pattern: オブジェクトのクローン生成
2. 構造に関するパターン
- Adapter Pattern: インターフェースの変換
- Decorator Pattern: 機能の動的追加
- Facade Pattern: 複雑なサブシステムの簡略化
- Proxy Pattern: オブジェクトへのアクセス制御
3. 振る舞いに関するパターン
- Observer Pattern: イベント通知の実装
- Strategy Pattern: アルゴリズムの切り替え
- Command Pattern: 操作のカプセル化
- Iterator Pattern: コレクションの走査
SOLID 原則チェック項目
S - Single Responsibility Principle (単一責任の原則)
O - Open/Closed Principle (開放閉鎖の原則)
L - Liskov Substitution Principle (リスコフの置換原則)
I - Interface Segregation Principle (インターフェース分離の原則)
D - Dependency Inversion Principle (依存性逆転の原則)
出力例
デザインパターン分析レポート
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
現在使用中のパターン
├─ Observer Pattern: EventEmitter (12 箇所)
├─ Factory Pattern: UserFactory (3 箇所)
├─ Singleton Pattern: DatabaseConnection (1 箇所)
└─ Strategy Pattern: PaymentProcessor (5 箇所)
推奨パターン
├─ [HIGH] Repository Pattern
│ └─ 対象: src/models/*.js
│ └─ 理由: データアクセスロジックの分離
│ └─ 例:
│ class UserRepository {
│ async findById(id) { ... }
│ async save(user) { ... }
│ }
│
├─ [MED] Command Pattern
│ └─ 対象: src/api/handlers/*.js
│ └─ 理由: リクエスト処理の統一化
│
└─ [LOW] Decorator Pattern
└─ 対象: src/middleware/*.js
└─ 理由: 機能の組み合わせ改善
SOLID 原則違反
├─ [S] UserService: 認証と権限管理の両方を担当
├─ [O] PaymentGateway: 新決済手段追加時に修正必要
├─ [D] EmailService: 具象クラスに直接依存
└─ [I] IDataStore: 使用されないメソッドを含む
リファクタリング提案
1. UserService を認証と権限管理に分割
2. PaymentStrategy インターフェースの導入
3. EmailService インターフェースの定義
4. IDataStore を用途別に分離
高度な使用例
# パターン適用の影響分析
/design-patterns --impact-analysis Repository
# 特定パターンの実装例生成
/design-patterns --generate Factory --for src/models/Product.js
# パターンの組み合わせ提案
/design-patterns --combine --context "API with caching"
# アーキテクチャパターンの評価
/design-patterns --architecture MVC
パターン適用例
Before (問題のあるコード)
class OrderService {
processOrder(order, paymentType) {
if (paymentType === "credit") {
// クレジットカード処理
} else if (paymentType === "paypal") {
// PayPal 処理
}
// 他の決済方法...
}
}
After (Strategy Pattern 適用)
// 戦略インターフェース
class PaymentStrategy {
process(amount) {
throw new Error("Must implement process method");
}
}
// 具象戦略
class CreditCardPayment extends PaymentStrategy {
process(amount) {
/* 実装 */
}
}
// コンテキスト
class OrderService {
constructor(paymentStrategy) {
this.paymentStrategy = paymentStrategy;
}
processOrder(order) {
this.paymentStrategy.process(order.total);
}
}
アンチパターン検出
- God Object: 過度に多くの責務を持つクラス
- Spaghetti Code: 制御フローが複雑に絡み合ったコード
- Copy-Paste Programming: 重複コードの過度な使用
- Magic Numbers: ハードコードされた定数
- Callback Hell: 深くネストしたコールバック
ベストプラクティス
- 段階的適用: 一度に多くのパターンを適用しない
- 必要性の検証: パターンは問題解決の手段であり目的ではない
- チーム合意: パターン適用前にチームで議論
- ドキュメント化: 適用したパターンの意図を記録