デザインパターン（GoF）

GoFデザインパターンは、Erich Gamma・Richard Helm・Ralph Johnson・John Vlissidesの4名が1994年に著した『Design Patterns: Elements of Reusable Object-Oriented Software』で提唱された23のパターン集だ。オブジェクト指向設計で繰り返し現れる問題とその解決策を名前付きのカタログとして整理したことで、設計の意図を短い名前で共有できる共通言語が生まれた。

パターンは生成・構造・振る舞いの3カテゴリに分類される。生成パターンはオブジェクトの生成方法を抽象化し、依存性を削減する（Factory Method・Abstract Factory・Singleton・Builder・Prototype）。構造パターンはクラスやオブジェクトの合成方法を扱い、柔軟な構造を実現する（Adapter・Decorator・Facade・Proxy・Composite）。振る舞いパターンはオブジェクト間の責任分担とアルゴリズムの変換を対象とする（Strategy・Observer・Command・Iterator・Template Method等）。

現代の静的型付け言語や関数型スタイルの普及により、一部のパターンはファーストクラス関数で自然に表現できるようになった。StrategyはCallback/関数として、CommandはPromise/非同期処理として実装されることも多い。重要なのはパターンの名前を当てはめることではなく、そのパターンが解決する「問題の構造」を理解することだ。

コードレビューで着目するポイント

Singletonが使われている箇所でグローバル状態や隠れた依存が生じていないか
Decoratorが深くネストしていないか・責務の読み取りが困難になっていないか
Factory Methodが条件分岐（switch/if-else）を隠蔽するために適切に使われているか
ObserverパターンでメモリリークやSubscription解除漏れが発生していないか
Template Methodが継承の代わりにCompositionで表現できないか（継承より合成）
Facadeがアンチパターン的な「God Object」化していないか
Proxyが透過的でない副作用（ロギング・認証）を持つ場合にその意図が明示されているか
パターンを適用した結果、シンプルな直接実装より複雑になっていないか

典型的なアンチパターン

Singleton乱用: テスタビリティのためにDIで渡せるオブジェクトをSingletonにしてしまう。ユニットテストで状態がリセットされず、テスト間の依存が生まれる。

パターンのための抽象化: 小さなユーティリティ関数にFactoryやStrategyを組み合わせた過剰な構造を与える。コードの意図よりパターンの型が目立ち、新規参加者の理解コストが上がる。

Observer連鎖によるデバッグ困難: 複数のObserver同士が互いにイベントを発行し合う。イベントの伝播経路がスパゲッティ化し、無限ループや予期しない副作用の原因になる。

参考リソース

Erich Gamma et al.『オブジェクト指向における再利用のためのデザインパターン』（ソフトバンクパブリッシング、1995）
Refactoring Guru — パターン別の図解と実装例 https://refactoring.guru/design-patterns
Joshua Kerievsky『Refactoring to Patterns』（Addison-Wesley、2004）
Martin Fowler「Is Design Dead?」— パターンの使いすぎへの警告
『Head First Design Patterns』（O’Reilly、2020）— 視覚的な入門書