この内容は古いバージョンです。最新バージョンを表示するには、戻るボタンを押してください。
バージョン:4
ページ更新者:atom
更新日時:2026-05-18 01:50:51

タイトル: デザインパターン

デザインパターンとはプログラムを実装する上での設計方針です。

デザインパターンに則り実装することで効率の良い開発が可能となります。先人が共通の問題に対して整理した「再利用可能な設計の型」で、Java / C# / PHP / Python など幅広い言語で活用できます。

それぞれのデザインパターンについては項目を参照してください。

本ページの子ページ

  • MVC — Model / View / Controller の3層分離。Webアプリで最も基本的なパターン

代表的なデザインパターン（GoF）

GoF（Gang of Four）の23パターンは、生成・構造・振る舞いの3カテゴリに分類されます。

生成に関するパターン

パターン目的
Singletonクラスのインスタンスを1つに限定する
Factory Methodインスタンス生成をサブクラスに委ねる
Abstract Factory関連オブジェクト群をまとめて生成
Builder複雑なオブジェクトを段階的に組み立てる
Prototype既存インスタンスをクローンして生成

構造に関するパターン

パターン目的
Adapter互換性のないインターフェースを橋渡し
Decorator既存オブジェクトに動的に機能を追加
Facade複雑なサブシステムに簡単なインターフェースを提供
Proxy本物のオブジェクトへのアクセスを代理
Composite個と複合を同じインターフェースで扱う（ツリー構造）

振る舞いに関するパターン

パターン目的
Observer状態変化を多数のオブジェクトに通知
Strategyアルゴリズムを切り替え可能にする
Template Method処理の骨格を親で、詳細を子で実装
Command処理をオブジェクト化し、実行・取消可能に
State状態に応じて振る舞いを切り替える
Iteratorコレクションを順次走査
Chain of Responsibility処理を連鎖させて該当者が処理

アーキテクチャパターン（GoFとは別系統）

パターン用途
MVCロジック・データ・表示の分離。Web開発で定番
MVP / MVVMクライアントUI向けの派生形（Android、Vue/React等）
Repositoryデータアクセスを抽象化
Service Layerビジネスロジックを集約するレイヤ
Layered Architectureプレゼンテーション・サービス・データの層分離
Clean Architecture / Hexagonal依存を内側だけに向ける設計

使うときの注意

  • パターンが先ではない — 問題があってからパターンを当てる。先に当てはめると過剰設計になる
  • SOLID原則とセットで考えると効果が大きい（オブジェクト指向言語共通参照）
  • 言語の慣用句を優先 — PHPの Singleton は言語機能で代替できる、Pythonでは関数で十分等
  • テスト容易性を最優先 — パターン採用でテストが書きにくくなるなら適用を見直す

関連