gof-identify

1 行での概要

提示された設計上の問題に適した GoF パターンを診断します。あるいは、パターンを候補から外して、よりシンプルな解決策を示します。

このスキルを使う場面

• ユーザーが設計上の問題を説明し、どのパターンが当てはまるか知りたい場合。
• 似ている 2 つのパターン（Strategy と State、Decorator と Proxy、Adapter と Facade）の違いに迷っている場合。
• パターンを導入しようとしているものの、それが適切かどうか確信がない場合。

このスキルを使わない場面

• ユーザーが使いたいパターンをすでに把握している場合は、そのパターンのスキル（例：gof-observer）に直接進みます。
• ユーザーが既存のコードを既知のパターンに合わせてリファクタリングしたい場合 → gof-refactor-to-pattern に案内します。
• ユーザーが誤用されているパターンを見つけるためにコードを監査したい場合 → gof-review に案内します。

コアコンテンツ

次の診断質問を、記載順に沿って確認します。

1. 何が変化していますか？

• アルゴリズム自体で、実行時にクライアントが選択するもの：gof-strategy。
• アルゴリズム自体で、オブジェクトのライフサイクルに応じて変化するもの：gof-state。
• アルゴリズム内の各ステップで、基底クラスが骨組みを固定するもの：gof-template-method。
• 実行時に、任意の組み合わせで振る舞いを追加・削除するもの：gof-decorator。

2. 生成に関する問題ですか？

• どの具象クラスをインスタンス化するかを選択する：gof-factory。
• 多数の（多くの場合は任意の）パラメーターや段階的な手順を使ってオブジェクトを組み立てる：gof-builder。
• 既存のオブジェクトをコピーし、いくつかのフィールドを変更して新しいインスタンスを作成する：gof-prototype。
• インスタンスを 1 つだけにする：gof-singleton — ただし、パターンが不要かどうかを、まず言語機能（Kotlin の object、DI のスコープ）で確認します。

3. 「あるオブジェクトを別のオブジェクトで包む」問題ですか？

• 振る舞いを追加する：gof-decorator。
• インターフェースを変更する：gof-adapter。
• アクセスを制御する（遅延／リモート／権限）：gof-proxy。
• サブシステムを単一のエントリーポイントの背後に隠してシンプルにする：gof-facade。

4. 構造上の問題ですか？

• 部分と全体の階層で、リーフとブランチを一様に扱う：gof-composite。
• 内部構造を公開せずにコレクションをたどる：gof-iterator。
• 互いに独立した 2 つの変化の軸がある（そうでなければ N×M のサブクラスが増加する）：gof-bridge。

5. 振る舞いや通信に関する問題ですか？

• 1 つのサブジェクトに、更新を必要とする複数の依存先がある：gof-observer。
• リクエストをオブジェクトとしてカプセル化する（キュー、ログ、取り消し）：gof-command。
• 要素クラスを変更せず、安定した階層に新しい操作を追加する：gof-visitor — ただし Kotlin では、sealed と網羅的な when を優先します。

6. どれにも当てはまりませんか？ そもそも GoF パターンが不要な問題かもしれません。よくあるケース：

• 単純な関数で解決できる。
• 言語機能がパターンに取って代わっている（Singleton には Kotlin の object、Decorator には by による委譲、Strategy には関数型）。
• 問題が設計ではなくドメインにある — ddd-design などに案内します。

判断のヒューリスティクス

• 「関数」や「言語機能」で解決できるなら、安易にパターンに頼らないでください。
• Strategy と State は構造が同じです。意図（クライアントが選択するか、ライフサイクルに応じて変化するか）で見分けてください。
• Decorator と Proxy は構造が同じです。意図（振る舞いを追加するか、アクセスを制御するか）で見分けてください。
• Adapter と Facade は適用範囲が異なります。単一クラスを別のインターフェースに適合させるか、サブシステムをよりシンプルなものにするかで区別します。

アンチパターン

• 問題を特定する前に「パターンを導入しよう」とする — 時期尚早な抽象化です。
• 実際にはそのパターンを使っていないのに、パターンにちなんだ名前（OrderManager、CustomerStrategy）を付ける — パターンありきの見せかけです。
• 問題が求めるものではなく、チームが興味を持っているものを基準にパターンを選ぶ。

関連項目

• 13 種類すべてのパターンスキル（gof-strategy、gof-observer、…）。
• gof-review — 「どのパターンが適切か」ではなく、「このコードはパターンを正しく使っているか」が問われている場合。
• gof-refactor-to-pattern — 移行先が決まっていて、「そこにどう移行するか」が問われている場合。

参考資料

• Head First Design Patterns（第2版）、第13章（「実世界のパターン」）— 実践でどのパターンが当てはまるかを見極める方法について解説しています。
• Design Patterns（Gamma、Helm、Johnson、Vlissides、1994年）— パターンの原典カタログであり、「意図／動機／適用可能性」という枠組みを示しています。