デザインパターンをClaudeと実装する

デザインパターンは「知っている」と「使いこなせる」の間に大きな壁があります。Claude Codeを使えば、その壁をぐっと低くできます。パターンの選定から実装、リファクタリングまで、対話しながら進めていきましょう。

パターンの選定をClaudeに相談する

まず「このコードにどのパターンが合うか」をClaudeに聞くところから始めましょう。次のようなプロンプトが効果的です。

以下のコードを見てください。注文処理ロジックが増えるたびにif文が膨らんでいます。
GoFパターンの中でリファクタリングに適したものを2〜3個提案し、
それぞれのトレードオフを教えてください。

[コードをここに貼り付ける]

具体的なコードを渡すことで、Claudeは抽象論ではなく「このケースならStrategyパターンが向いている、なぜなら〜」という踏み込んだ回答を返してくれます。選択肢を複数出してもらい、自分のチームの規模や将来の拡張方針と照らし合わせながら決めるのが良いアプローチです。

※リファクタリング: 外部から見た動作を変えずに、コードの内部構造を整理・改善すること。※プロンプト: AIへの指示文。Claude Codeへの指示の質がそのまま出力の質に影響する。

Factoryパターンを段階的に実装する

パターンが決まったら、一気に完成形を作らず段階的に進めましょう。たとえばFactory Methodパターンの場合、次のように頼んでみてください。

TypeScriptでFactory Methodパターンを使って通知クラス（Email・Slack・SMS）を実装してください。
まずインターフェース定義だけ出力し、次のステップで具体クラスを追加します。

Claudeが出力したインターフェースを確認・修正してから次のステップへ進むことで、方向性のズレを早期に防げます。

// Claudeが出力したインターフェース例
interface Notifier {
  send(message: string, to: string): Promise<void>;
}

abstract class NotifierFactory {
  abstract createNotifier(): Notifier;

  async notify(message: string, to: string): Promise<void> {
    const notifier = this.createNotifier();
    await notifier.send(message, to);
  }
}

※TypeScript: JavaScriptに型定義を追加した言語。型チェックによりバグを事前に発見しやすくなる。

Repositoryパターンでテスタビリティを高める

アーキテクチャパターンの中でも特に有用なRepositoryパターンは、テストとの相性が抜群です。Claudeには実装と同時にモックも依頼しましょう。

UserRepositoryインターフェースとその実装（Prisma使用）、
それからJestテスト用のInMemoryUserRepositoryも合わせて生成してください。

こう依頼すると、本番実装とテスト用モックが一貫したインターフェースで揃い、すぐにテストを書き始められます。

パターンの適用はゴールではなく手段です。Claudeと対話しながら「このプロジェクトに本当に必要な設計」を一緒に見つけていきましょう。

※モック: テスト時に本物の代わりに使う偽のオブジェクトや関数。外部APIや DBへの実際の通信を避けるために使う。