デザインパターン入門(GoF) 目的と効果をやさしく解説

2025年10月29日

その他

デザインパターンは、よくある設計の問題に対する再利用しやすい解決の「型」です。

本記事ではGoF(23パターン)の目的と効果を、初学者でも迷わないように整理します。

名前の意味、使う場面、導入のコツを段階的に理解できるように解説します。

デザインパターン(GoF)入門の基本

デザインパターンの定義

パターンとは何か

デザインパターンは、繰り返し現れる設計上の問題に対する、名前のついた一般解です。

具体的には、ある状況で機能する設計の「定石」を文章化したもので、他のプロジェクトでも再利用できる知識として共有されます。

初学者はパターン=名前がついた設計のコツと捉えると理解しやすく、コードの暗記ではなく考え方の再利用だと意識することが大切です。

GoFとは

GoFは「Gang of Four(4人組)」の略称で、エリック・ガンマら4名がまとめた23の代表的なオブジェクト指向デザインパターン集を指します。

GoFはパターンの基礎語彙と分類を提供し、チームで同じ言葉で議論できる土台を作りました。

書籍全体を覚える必要はありませんが、名前と目的を知るだけでも設計の会話が驚くほどスムーズになります。

パターンの基本要素

パターンは多くの場合、次の要素で記述されます。

名前・問題・解決・結果の4点を押さえるだけで、意図の理解がぐっと進みます。

要素	意味	初心者の捉え方
名前	パターンの呼称	会話のためのラベル
問題	どんな状況の困りごとか	いつ使うかを示す合図
解決	どのように構成するか	図や関係の雛形
結果	得られる利点と副作用	効果と注意点のメモ

目的

共通言語を持つ

デザインパターンの最大の目的は、設計を素早く正確に共有する共通言語をチームに与えることです。

「ここはStrategyで」「ここはAdapterが要りそう」と言うだけで、意図が一瞬で伝わります。

これにより設計レビューの時間が短縮され、誤解による手戻りが減ります。

再発明のコストを下げる

既に多くの現場で機能した解決を再利用することで、試行錯誤の回数とリスクを減らし、学習コストを抑えられます。

ただしパターンは万能ではなく、現場に合わせて軽量にアレンジする姿勢が重要です。

効果

設計の見通しと変更耐性

パターンに沿って役割を分割することで、変更の影響範囲が明確になります。

変更に強く、テストしやすく、読みやすい設計へ近づく効果が期待できます。

加えて、構造が定型化されることでレビューの観点も共有しやすくなります。

学習と引き継ぎが楽になる

新メンバーが入っても、パターン名と意図を説明すれば理解が早まります。

名前付きの構造はナレッジの圧縮効果を生み、引き継ぎの負担を軽くします。

ドキュメントや図にもパターン名を明記すると、後から見返すときの道しるべになります。

使いどころ

こんなときに役立つ

使いどころは「状況のサイン」で覚えると簡単です。

分岐だらけ・クラスが肥大・外部APIが噛み合わないといったサインが出たら検討の合図です。

例えば、条件分岐でアルゴリズムを切り替えるならStrategy、通知のばらまきならObserver、合わないAPIの橋渡しならAdapterが候補になります。

分岐やif/switchが増えてアルゴリズム切り替えがつらい場合はStrategy
あるイベントを複数箇所へ通知したい場合はObserver
既存のインターフェースと外部APIが噛み合わない場合はAdapter

「どのパターンを使うか」より「どんな問題に直面しているか」を先に言葉にすると選択を誤りにくくなります。

GoFデザインパターンの3分類

生成パターン

目的と考え方

生成パターンは、オブジェクトの作り方を柔軟にするためのパターン群です。

newの場所を分散させず、交換や拡張を考えやすくします。

初心者は「生成を1か所に寄せる」「作り方を隠す」と覚えると入りやすいです。

主な例の位置づけ

Singletonは唯一実体の提供、Factory Methodは派生クラスに生成責任を渡す、Abstract Factoryは関連オブジェクト群の一括生成に向きます。

まずはFactory Method→Singletonの順で把握すると負担が少ないです。

構造パターン

目的と考え方

構造パターンは、クラスやオブジェクト同士の組み合わせ方を整えるためのパターンです。

大きな仕組みを部品の合成で作れるようにし、置き換えやラップで互換性を確保します。

Adapterは「合わない形を変換するアダプター」です。

振る舞いパターン

目的と考え方

振る舞いパターンは、オブジェクト間のやり取りやアルゴリズムの分担方法を整理するパターンです。

Strategyは入れ替え可能な手順、Observerは通知の仕組みで、どちらも分岐を減らして見通しを良くします。

区分	主な狙い	キーワード	代表例(初心者向け)
生成	作り方を隠す/集約する	生成責任、唯一性	Factory Method、Singleton
構造	組み合わせ方を整える	合成、ラップ、互換	Adapter
振る舞い	やり取りと手順を整理	切り替え、通知	Strategy、Observer

「作る」「組む」「動かす」の3視点で覚えると、どの分類のパターンを選ぶべきかが直感的になります。

初心者にやさしい代表パターン

Singleton

何を解決するか

アプリ全体で1つだけ存在すれば良いもの(設定、ログ、接続プールなど)を、常に同じインスタンスで提供する仕組みです。

どこからでも同じ実体にアクセスできるため、一貫性が保たれます。

使いどころ

「唯一でよい」「共有が自然」「生成コストが大きい」の3条件が揃うときに向いています。

状態を持たせすぎない設計にしておくとテストが楽になります。

注意点

多用は禁物です。

グローバル状態の温床になり、テストが難しくなります。

DI(依存の注入)や引数渡しで代替できるなら、まずはそちらを検討しましょう。

Factory Method

何を解決するか

生成の分岐が散らばると変更が大変です。

Factory Methodは、具象クラスの選択と生成を1か所に寄せ、呼び出し側を具体型から切り離します。

これにより新しい種類の追加がしやすくなります。

使いどころ

入力に応じて作るオブジェクトが変わる、プラグインの差し替えがある、テストで偽物を差したい、といった場面に有効です。

「newを直接書かない」が合図だと覚えると迷いません。

小さなイメージ

例えばファイル読み込みで、拡張子が「.json」ならJsonReader、「.csv」ならCsvReaderといった具合に、拡張子→適切なリーダーの選択を工場に任せるイメージです。

Strategy

何を解決するか

ifやswitchでアルゴリズムを切り替えると、分岐が増えて読みづらくなります。

Strategyは、アルゴリズムを入れ替え可能な部品として用意し、実行時に差し替えるアプローチです。

使いどころ

並び替え方法、料金や割引の計算、キャッシュ方針など、ルールは同じだが手順だけ違う場合に向いています。

ユニットテストも部品ごとに独立して書けます。

小さなイメージ

「通常配送」「お急ぎ」「店舗受取」といった送料計算を、それぞれのStrategyで表現します。

呼び出し側は「どの戦略を使うか」だけを受け取り、計算の中身を知りません。

Observer

何を解決するか

ある出来事を、関心のある複数の相手へ自動で通知したいときに使います。

発行者が1回知らせるだけで、購読者がそれぞれ反応する仕組みです。

使いどころ

UIイベント、在庫の変動通知、状態変更ログなど、イベントが発生→関連処理をばらけて反応させたい場面で有効です。

実装はシンプルでも、通知回数や順序の設計に配慮しましょう。

小さなイメージ

「在庫が0になった」イベントが起きたら、ページ表示更新、メール通知、レコメンド更新などがそれぞれ動く形です。

発行側は購読者の中身を知らずに済むため、結合度を下げられます。

Adapter

何を解決するか

使いたいライブラリのインターフェースが自分のコードと合わない、という摩擦を解消します。

既存の形を変えずに、外部の形だけ自分の想定に合わせる変換アダプターを挟む考え方です。

使いどころ

置き換えが難しい外部API/ライブラリを、既存の呼び出し側に無改造でつなげたいときに適しています。

本体をいじらず橋渡しで解決できるのが魅力です。

小さなイメージ

温度センサーが華氏しか返さないなら、Adapterで摂氏へ変換してから渡します。

呼び出し側は「いつも通り摂氏で受け取る」だけで済みます。

パターン	目的(ひとことで)	主な効果	典型的なサイン
Singleton	唯一の実体	一貫性、共有、簡便	同じ設定/状態を全体で共有
Factory Method	生成を隠す	交換容易、テスト容易	newの分岐が増えている
Strategy	手順を差し替える	分岐削減、テスト容易	if/switchが肥大
Observer	通知をばらまく	疎結合、拡張容易	同じイベントに複数反応
Adapter	形を合わせる	互換性、影響範囲縮小	外部APIと型/形が不一致