gof-review

1 行の要約

GoF デザインパターンを使用すると主張している（または使用しているように見える）コードを監査し、パターンの名前だけでなく、その意図、構造、トレードオフが守られているかを確認します。

このスキルを使う場面

• プルリクエストでパターンが導入され、レビュー担当者が体系的に確認したい場合。
• コードベースに *Factory、*Strategy、*Adapter、*Manager があちこちにあり、実際に使われているものと、パターンを装っているだけのものを見分けたい場合。
• パターンが誤って適用されている（過剰設計、誤った命名、意図の取り違え）と疑われる場合。

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

• ユーザーがパターンの「導入」を望んでいる → gof-identify または gof-refactor-to-pattern に案内します。
• ユーザーがコードレベルのパターンではなく、ドメインモデリングの問題を抱えている → ddd-review または ddd-design に案内します。

主な内容

対象のファイルまたはモジュールを、以下のパターン誤用の一覧に照らしてレビューします。指摘ごとに、重大度（blocker ／ major ／ minor）、該当箇所、修正方法を説明するパターンスキルを報告します。

パターンを装っているだけ。 OrderManager、CustomerStrategy、PaymentFactory という名前のクラスが、実際にはパターンを実装しておらず、名前を借りているだけの場合です。パターンについて学んだものの、実際には採用していないコードベースでよく見られます。修正方法：ドメインの動詞に合わせて名前を変更する（ddd-ubiquitous-language を参照）か、実際にパターンを適用します。

どこにでもシングルトン。 getInstance() の呼び出しがコードベース中に散在し、グローバル状態を保持してテストを妨げている場合です。修正方法：依存性注入を導入し、シングルトンは真に唯一であるべきリソースに限って使用します。gof-singleton を参照してください。

戦略が 1 つしかないストラテジー。 2 つ目を導入する予定がないのに、実装が 1 つだけの Strategy インターフェースがある場合です。メリットがないまま間接性だけが増します。修正方法：2 つ目の戦略が登場するまでは、戦略をインライン化します。

肥大化したファサード。 すべてのサブシステムの詳細を把握し、あらゆるもののセッターまで含むようになった Facade クラスです。修正方法：役割を絞った複数のファサードに分割するか、「ファサード」がアプリケーションサービスになったことを認めます。

デコレーターの寄せ集め。 呼び出し順が重要なのに、その順序がどこにも規定されていないデコレーターの連鎖です。修正方法：必要な合成順序を文書化するか、型で順序が定まるように再構成します。

オブザーバーのリーク。 登録されたまま登録解除されないオブザーバーが、サブジェクトを永久に生存させている場合です。修正方法：detach() を明示的に徹底する、弱参照を使う、または実際のイベントバスを使用します。

ビジネスロジックを担うアダプター。 翻訳にとどまらず、実際の計算まで行うようになったアダプターです。修正方法：ロジックを適切な場所へ移し、アダプターは翻訳に専念させます。

名前付きのパターンの意図を満たしていないラッパークラス。 動作を追加する *Proxy（これは Decorator です）。インターフェースを変更する *Decorator（これは Adapter です）。ライフサイクル状態を保持する *Strategy（これは State です）。修正方法：意図に合うように名前を変更するか、構造を見直します。

コンポジションが要点なのに継承階層を使っている。 サブクラスのツリーとして実装された「Decorator」です。コンポジションを継承より優先するという、このパターンの主な価値を損ないます。修正方法：コンポジションを使うようにリファクタリングします。

判断の目安

• 重大度は影響範囲に応じて決めます。多くの呼び出し元に影響するパターンの誤用は、同じ誤用が 1 か所だけにある場合より重大です。
• 意見ではなく、指摘を報告します。各指摘には行範囲と関連するパターンスキルを記載します。
• コード上の違反を示さずに、パターン名だけを挙げてはいけません。
• パターン名が正しくても、不必要に適用されている（時期尚早な抽象化）なら指摘します。

アンチパターン

• 明らかに誤ったパターンの使い方をしているコードに、安易にお墨付きを与えること。
• 命名だけをレビューすること。OrderManager は一貫性のあるドメイン概念であれば問題ない場合もあります。確認すべきなのは、コードが名前から想定される役割を果たしているかどうかです。
• コード上の違反を示さずにパターン名を挙げること。

関連項目

• 13 種類すべてのパターンスキル — 指摘では関連するスキルを挙げます。
• gof-identify — レビュー中に「どのパターンにすべきか」という質問が出た場合に使用します。
• ddd-review — ドメインモデリングのレビューに使用します（デザインパターンのレビューとは別の観点です）。

参考資料

• Head First Design Patterns（第2版）、第13章 — 過剰適用への警告を含む、実世界でのパターン。
• Design Patterns（GoF、1994）— 各パターンの原著における「意図」のセクション。意図との不一致は、誤用の最も一般的な原因です。