インターフェースの設計

「A Philosophy of Software Design」の「Design It Twice」に基づいています。最初の考えが最善とは限りません。複数の根本的に異なる設計を生成し、比較します。

ワークフロー

1. 要件の収集

設計前に、以下を理解します:

• このモジュールはどのような問題を解決するのか?
• 呼び出し元は誰か? (他のモジュール、外部ユーザー、テスト)
• 主な操作は何か?
• 制約条件はあるか? (パフォーマンス、互換性、既存のパターン)
• 内部に隠すべきものと公開すべきものは何か?

質問: 「このモジュールは何をする必要があるのか? 誰が使うのか?」

2. 設計の生成 (並列サブエージェント)

Task ツールを使って、3個以上のサブエージェントを同時に起動します。各エージェントは根本的に異なるアプローチを生成する必要があります。

各サブエージェント向けのプロンプトテンプレート:

Design an interface for: [モジュールの説明]

Requirements: [収集した要件]

Constraints for this design: [各エージェントに異なる制約を割り当て]
- Agent 1: "Minimize method count - aim for 1-3 methods max"
- Agent 2: "Maximize flexibility - support many use cases"
- Agent 3: "Optimize for the most common case"
- Agent 4: "Take inspiration from [specific paradigm/library]"

Output format:
1. Interface signature (types/methods)
2. Usage example (how caller uses it)
3. What this design hides internally
4. Trade-offs of this approach

3. 設計の提示

各設計を以下とともに表示します:

1. インターフェースシグネチャ - 型、メソッド、パラメータ
2. 使用例 - 呼び出し元が実際に使用する方法
3. 隠されているもの - 内部に保持される複雑性

各アプローチを順序を追って提示し、ユーザーが比較前に各設計を理解できるようにします。

4. 設計の比較

すべての設計を表示した後、以下について比較します:

• インターフェースの単純性: メソッドが少ない、パラメータがシンプル
• 汎用性と特殊性: 柔軟性 vs 焦点
• 実装効率: インターフェースの形が効率的な実装を可能にするか?
• 深さ: 小さなインターフェースで大きな複雑性を隠す (良い) vs 大きなインターフェースで薄い実装 (悪い)
• 正しく使いやすさ vs 誤用しやすさ

テーブルではなく、散文で取り組みを議論します。設計が最も異なる部分を強調します。

5. 統合

最良の設計は、複数のオプションから洞察を組み合わせることが多くあります。質問します:

• 「どの設計があなたの主な用途に最も適合しているか?」
• 「他の設計から組み込む価値のある要素はあるか?」

評価基準

「A Philosophy of Software Design」から:

インターフェースの単純性: メソッドが少ない、パラメータがシンプル = 学習と正しい使用が容易。

汎用性: 将来のユースケースに変更なしで対応できます。ただし過度な一般化に注意。

実装効率: インターフェースの形が効率的な実装を可能にするか? それとも不格好な内部実装を強制するか?

深さ: 小さなインターフェースで大きな複雑性を隠す = 深いモジュール (良い)。大きなインターフェースで薄い実装 = 浅いモジュール (避けるべき)。

アンチパターン

• サブエージェントに類似した設計を生成させない - 根本的な違いを強制する
• 比較をスキップしない - 価値は対比にある
• 実装しない - これは純粋にインターフェースの形についてのものです
• 実装の労力に基づいて評価しない