はじめに
「デザインパターン」「GoF」という言葉は、オブジェクト指向言語を学んでいると必ずと言っていいほど耳にします。
しかし、いざ「23個あるらしいけど、それぞれ何が違うの?」と聞かれると、答えに詰まる人も多いはずです。
本記事は、これから始まるデザインパターン解説シリーズの総集編として、デザインパターン全体の考え方と23種類の一覧を整理します。
個々のパターンの詳細・Javaのサンプルコードは、それぞれ別記事で解説します。
デザインパターンとは
デザインパターン(Design Pattern)とは、ソフトウェア設計においてよく起こる問題に対する、再利用可能な設計上の「型」「解決策のひな形」のことです。
特定のプログラミング言語の構文や、コピペで使える完成コードそのものではなく、「こういう状況では、こういうクラス構成にすると上手くいく」という設計方針のテンプレートという位置づけです。
料理のレシピに例えると分かりやすいかもしれません。
レシピは「材料と手順」を示しますが、実際に使う食材の銘柄や火加減は作る人・状況によって変わります。
デザインパターンも同様に、「どういう役割のクラスを、どう関係づけるか」という設計の骨格を示すものであり、実際のクラス名・実装の細部はプロジェクトごとに調整されます。
なぜデザインパターンが重要なのか
デザインパターンを学ぶ意義は、主に3つあります。
- 車輪の再発明を防ぐ: 先人たちが試行錯誤して見つけた「上手くいく設計」を、一から自分で発見し直す必要がなくなる
- 共通言語になる: 「ここはObserverパターンで」と言うだけで、設計者同士が同じ構造を頭に思い浮かべられる。コードレビューや設計相談の効率が上がる
- 変更に強い設計の型を学べる: 多くのデザインパターンは「変化する部分」と「変化しない部分」を分離する工夫を含んでおり、将来の仕様変更に強いコードを書く訓練になる
GoF(Gang of Four)とは
GoFとは、1994年に書籍『Design Patterns: Elements of Reusable Object-Oriented Software(邦題: オブジェクト指向における再利用のためのデザインパターン)』を執筆した4人の著者、Erich Gamma・Richard Helm・Ralph Johnson・John Vlissidesの総称です。
「4人組」を意味する"Gang of Four"の頭文字から、この呼び名が定着しました。
この書籍で体系的に整理された23種類の設計パターンが、現在「GoFデザインパターン」「GoFの23パターン」として広く知られています。
デザインパターンという分野自体はGoF以降も発展していますが(アーキテクチャパターンや、より現代的な言語機能を前提としたパターンなど)、GoFの23パターンは今なおオブジェクト指向設計の共通基盤として学ばれ続けています。
GoFの23パターン:3つの分類
GoFは23個のパターンを、「何を解決するか」という目的によって3つのグループに分類しました。
1. 生成に関するパターン(Creational Patterns):5種類
オブジェクトの生成方法に関するパターン群です。
「newで直接インスタンス化する」という素朴な方法には、「生成するクラスが変わるたびにコードを修正しないといけない」「複雑な初期化手順をあちこちに書いてしまう」といった課題があります。
生成に関するパターンは、こうした課題を解決します。
| パターン名 | 概要 |
|---|---|
| Singleton(シングルトン) | あるクラスのインスタンスが、アプリケーション全体でただ1つだけであることを保証する |
| Factory Method(ファクトリーメソッド) | インスタンス生成処理をサブクラスに委ねることで、生成するクラスを柔軟に切り替えられるようにする |
| Abstract Factory(抽象ファクトリー) | 互いに関連する複数のオブジェクト群を、一貫性を保ちながらまとめて生成する |
| Builder(ビルダー) | 複雑な初期化手順を持つオブジェクトを、段階的に組み立てて生成する |
| Prototype(プロトタイプ) | 既存のオブジェクトを複製(クローン)することで、新しいオブジェクトを生成する |
2. 構造に関するパターン(Structural Patterns):7種類
クラスやオブジェクトをどう組み合わせて、より大きな構造を作るかに関するパターン群です。
異なるインターフェースを持つクラス同士をつなぎ合わせたり、オブジェクトの構成を柔軟に変更できるようにしたりする工夫が中心です。
| パターン名 | 概要 |
|---|---|
| Adapter(アダプター) | インターフェースが異なるクラス同士を、変換用のクラスを挟むことで接続できるようにする |
| Bridge(ブリッジ) | 機能の階層と実装の階層を分離し、それぞれ独立に拡張できるようにする |
| Composite(コンポジット) | 個々のオブジェクトと、それらの集合(グループ)を同じインターフェースで扱えるようにする |
| Decorator(デコレーター) | 既存オブジェクトを包み込むことで、動的に機能を追加する |
| Facade(ファサード) | 複雑なサブシステム群に対して、シンプルな単一の窓口(インターフェース)を提供する |
| Flyweight(フライウェイト) | 共有可能なオブジェクトを再利用することで、メモリ使用量を削減する |
| Proxy(プロキシ) | 本来のオブジェクトへのアクセスを代理オブジェクトが仲介し、アクセス制御や遅延生成等を行う |
3. 振る舞いに関するパターン(Behavioral Patterns):11種類
オブジェクト間の責任の分担や、やり取り(コミュニケーション)の方法に関するパターン群です。
3分類の中で最も数が多く、扱う課題領域も多岐にわたります。
| パターン名 | 概要 |
|---|---|
| Chain of Responsibility(責任の連鎖) | 複数の処理者を鎖状につなぎ、要求を処理できる者が現れるまで順番に渡していく |
| Command(コマンド) | 要求(操作)をオブジェクトとしてカプセル化し、実行・取り消し・キューイングを可能にする |
| Interpreter(インタープリター) | 特定の文法規則に従った文を解釈・実行する仕組みを、クラス構造として表現する |
| Iterator(イテレーター) | 集合の内部構造を意識せずに、要素を順番に走査できるようにする |
| Mediator(メディエーター) | オブジェクト間の複雑なやり取りを、仲介役のオブジェクトに一元化する |
| Memento(メメント) | オブジェクトの内部状態を、カプセル化を破らずに保存・復元できるようにする |
| Observer(オブザーバー) | あるオブジェクトの状態変化を、それを購読している複数のオブジェクトに自動的に通知する |
| State(ステート) | オブジェクトの内部状態によって振る舞いを切り替える処理を、状態ごとのクラスに分離する |
| Strategy(ストラテジー) | アルゴリズム(処理方法)をクラスとして切り出し、実行時に交換可能にする |
| Template Method(テンプレートメソッド) | 処理の大枠(骨格)を親クラスで定義し、詳細な手順の一部をサブクラスに委ねる |
| Visitor(ビジター) | データ構造と、そのデータに対する処理を分離し、既存のクラスを変更せずに新しい処理を追加できるようにする |
学び方の指針
23個を丸暗記しようとする必要はありません。
それぞれのパターンは「どんな問題を解決するために生まれたか」という背景とセットで理解すると定着しやすくなります。
本シリーズでも、各パターンの記事では「解決したい課題」「クラス構成」「Javaでのサンプルコード」「実際に使われる場面」の順に解説していきます。
まずは3分類の大枠(生成・構造・振る舞い)を頭に入れた上で、興味のあるパターンから読み進めてみてください。
まとめ
| 項目 | 内容 |
|---|---|
| デザインパターン | ソフトウェア設計でよく起こる問題への、再利用可能な設計のひな形 |
| GoF | 書籍『Design Patterns』の著者4人(Gamma・Helm・Johnson・Vlissides)の総称 |
| GoFの23パターン | 生成に関するパターン(5)・構造に関するパターン(7)・振る舞いに関するパターン(11)の3分類 |
| 学び方 | 各パターンが「どんな問題を解決するか」とセットで理解すると定着しやすい |
おすすめ書籍
GoFの23パターンをより深く学びたい方には、以下の書籍がおすすめです。
Java言語のサンプルコードとUMLを使い、初心者にもわかりやすく解説されています。
Java言語で学ぶデザインパターン入門 第3版 [ 結城 浩 ]
※本リンクはアフィリエイトリンクを含みます。
参考
- Gamma, E., Helm, R., Johnson, R., Vlissides, J. "Design Patterns: Elements of Reusable Object-Oriented Software" (1994)
- Gang of Four Design Patterns - GeeksforGeeks
- Design Patterns - Refactoring.Guru


