デザインパターンとは——「再利用可能な解決策」の図鑑

デザインパターンとは何か

プログラミングをしていると、「このコードどこかで見たな」「似たような問題を以前も解いた気がする」という場面によく出くわします。実はその「似たような問題」は、多くの開発者が繰り返し直面してきた共通の課題です。

デザインパターンとは、そうした繰り返し現れる設計上の問題に対する「名前のついた再利用可能な解決策」です。コードそのものではなく、「どういう構造で設計すれば問題を解けるか」というテンプレートです。

1994年に Gang of Four（GoF）と呼ばれる4人の著者（Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides）が著書 Design Patterns: Elements of Reusable Object-Oriented Software で23のパターンを体系化しました。これが今もOOPにおける設計の共通言語として使われています。

3つの分類

GoFの23パターンは、目的によって3つのカテゴリに分類されます。

生成パターン（Creational）

オブジェクトの生成方法に関するパターンです。どのように、どのタイミングでオブジェクトを作るかを整理します。

パターン	概要
Singleton	インスタンスをひとつに制限する
Factory Method	生成を子クラスに委ねる
Abstract Factory	関連オブジェクト群をまとめて生成する
Builder	複雑なオブジェクトを段階的に組み立てる
Prototype	既存オブジェクトをコピーして生成する

構造パターン（Structural）

クラスやオブジェクトの組み合わせ方に関するパターンです。より大きな構造を作るための設計を提供します。

パターン	概要
Adapter	互換性のないインターフェースをつなぐ
Bridge	実装と抽象を分離する
Composite	木構造でオブジェクトを扱う
Decorator	機能を動的に追加する
Facade	複雑なサブシステムを単純なインターフェースで包む
Flyweight	多数のオブジェクトを効率的に共有する
Proxy	別のオブジェクトへのアクセスを制御する

振る舞いパターン（Behavioral）

オブジェクト間の通信や責任の割り当てに関するパターンです。

パターン	概要
Chain of Responsibility	要求を連鎖的に処理する
Command	操作をオブジェクトとしてカプセル化する
Iterator	コレクションを順番に走査する
Mediator	オブジェクト間の通信を一元管理する
Memento	オブジェクトの状態を保存・復元する
Observer	状態変化を他のオブジェクトに通知する
State	状態によって振る舞いを切り替える
Strategy	アルゴリズムを差し替え可能にする
Template Method	アルゴリズムの骨格を定義する
Visitor	クラスを変えずに操作を追加する

なぜパターンを学ぶのか

1. 共通言語として使える

「ここはStrategyパターンで実装しよう」と言えば、チームメンバーに設計の意図がすぐ伝わります。コードを全部読まなくても構造が想像できるようになります。

2. 設計の選択肢が増える

問題に直面したとき、「とりあえず if 文で分岐」以外の選択肢を持てるようになります。パターンは引き出しです。

3. 保守性・拡張性が上がる

パターンに従った設計はSOLID原則と相性がよく、変更に強いコードになりやすいです。

「問題→パターン→解決」の考え方

デザインパターンは「このパターンを使いたいから使う」のではなく、「この問題を解決するのに適したパターンはどれか」と考えるのが正しい使い方です。

問題: 通知方法（Email/SMS/Push）を実行時に切り替えたい
      ↓
考える: if文で分岐? → 追加のたびに修正が必要、テストが難しい
      ↓
パターン: Strategy → 通知アルゴリズムをインターフェースに閉じ込める
      ↓
解決: 通知方法を差し替え可能な設計になり、追加もテストも容易

このシリーズで扱うパターン

このシリーズでは、実務でよく登場する以下のパターンをPHP 8.xのコードで解説します。

Singleton — インスタンスをひとつに制限する
Factory Method — オブジェクト生成を子クラスに任せる
Builder — 複雑なオブジェクトを段階的に組み立てる
Strategy — アルゴリズムを差し替え可能にする
Observer — イベントと通知を疎結合にする
Decorator — 機能を動的に追加する
Repository — データアクセスをビジネスロジックから切り離す
Command — 操作をオブジェクトとしてカプセル化する
Adapter — 互換性のないクラスをつなぐ
Template Method — アルゴリズムの骨格を定義する

各回ではLaravelとの対応も示しながら、「このパターンはどこで使われているか」を具体的に見ていきます。

まとめ

デザインパターンは繰り返し現れる設計問題への「名前のついた解決策」
GoF 23パターンは生成・構造・振る舞いの3カテゴリに分類される
パターンはコードではなく設計のテンプレート。チームの共通言語になる
「パターンありき」ではなく「問題ありき」で選ぶのが正しい使い方

次回は最もシンプルかつよく議論されるパターン、Singleton を取り上げます。