デザインパターンとは？
定義と意義
- デザインパターンは、よくある設計課題に対する再利用可能な解決方法のテンプレートである
- 「どう書くか」ではなく「なぜその設計が有効か」という観点での知識集
- 一般的に GoF（Gang of Four）による
23の基本パターンが広く知られている
パターンの分類（GoF の 3 分類）
| 分類 | 意味 | 主なパターン |
|---|---|---|
Creational（生成） | インスタンスの生成方法に関する設計 | Singleton, Factory Method, Abstract Factory, Builder, Prototype |
Structural（構造） | オブジェクトの構成・結合に関する設計 | Adapter, Decorator, Facade, Composite, Proxy, Bridge, Flyweight |
Behavioral（振る舞い） | オブジェクトの振る舞いや協調に関する設計 | Strategy, Observer, Command, State, Template Method, Iterator, Mediator, Chain of Responsibility, Visitor, Memento, Interpreter |
パターンマップ（一覧）
生成（Creational）
├─ Singleton : 単一インスタンスの共有
├─ Factory Method : 生成をサブクラスに委ねる
├─ Abstract Factory : 関連オブジェクトをまとめて生成
├─ Builder : 複雑な生成手順の分離
└─ Prototype : インスタンスの複製
構造（Structural）
├─ Adapter : インターフェースの互換
├─ Bridge : 抽象と実装の分離
├─ Composite : 階層構造の統一管理
├─ Decorator : 機能の追加をラップで実現
├─ Facade : 簡易な窓口を提供
├─ Flyweight : メモリ効率化のための共有
└─ Proxy : 制御や遅延処理の代理
振る舞い（Behavioral）
├─ Strategy : アルゴリズムの切り替え
├─ Observer : 状態変更の通知
├─ Command : 処理のオブジェクト化
├─ State : 状態ごとの処理分離
├─ Template Method : 処理枠の固定＋差分実装
├─ Chain of Resp. : 処理責任の委譲チェーン
├─ Iterator : 集合の走査
├─ Mediator : 仲介者による依存制御
├─ Visitor : 処理を構造外に分離
├─ Memento : 状態の保存・復元
└─ Interpreter : 文法ルールの評価
よく使うデザインパターンと導入理由（Top 10）
| パターン | 解決する課題 | 主な利用シーン |
|---|---|---|
Singleton | グローバル状態の一元管理 | 設定・ログ・DB 接続など |
Strategy | 条件分岐の整理 | 課金処理、認証切替など |
Observer | 状態変化の通知 | UI 更新、Pub/Sub 機構 |
Factory Method | 実装依存を回避 | プロトコル別クライアント生成 |
Decorator | 機能の追加 | ログ付加、権限処理 |
Adapter | API の互換化 | 外部連携、レガシー統合 |
Command | 処理のカプセル化 | Undo/Redo、バッチ実行 |
Facade | 複雑 API の簡易化 | サービスラッパー |
Template Method | 差分処理の抽象化 | 出力処理、共通ワークフロー |
State | 状態に応じた処理分離 | ウィザード、接続状態管理 |
記憶と実務に結びつけるヒント
- パターン名だけではなく、 「使った場面」や「過去の経験」 と一緒に覚えると定着しやすい
- 「この設計、見たことある」「似たことを別の案件でやったな」と思える瞬間が重要
リファクタリングの目的再確認
| 目的 | 説明 |
|---|---|
| 保守性の向上 | コードの読みやすさと理解のしやすさ |
| 拡張性の確保 | 機能追加時の安全性と効率 |
| バグの予防 | 副作用や修正漏れを減らす |
| 開発速度の維持 | レビューやテストの効率向上 |
「動いてるから OK」ではなく、「安全に進化できる構造」を目指す
デザインパターンは、未来の開発効率を支える“再利用可能な設計”の知恵である。