はじめに
ソフトウェア設計では、処理の種類を切り替える、既存の部品を別の形式へつなぐ、オブジェクトの生成方法を利用側から分離するといった問題が繰り返し現れます。デザインパターンは、こうした問題を毎回ゼロから解き直さず、過去の設計経験を解決候補として利用するためのものです。
ただし、パターン名を先に決めて形だけを当てはめると、クラスやインターフェースが増え、単純だった処理を追いにくくすることがあります。この記事では、デザインパターンの意味、GoFの3分類、SOLID原則との違い、設計での使い方を解説します。
この記事で分かること
- デザインパターンとは何か
- GoFデザインパターンの3分類
- SOLID原則との役割の違い
- パターンを選び、適用する方法
デザインパターンとは
デザインパターンとは、特定の文脈で繰り返し現れる設計上の問題と、その問題を解く基本構造、適用した結果を、再利用できる形で整理したものです。完成したプログラムや、そのまま写す設計図ではありません。どのような状況で問題が起き、どの役割がどのように協力し、適用後に何が変わるかを理解して使います。
パターンには名前が付いているため、クラス図やコードの詳細を示す前に、設計の狙いを共有しやすくなります。一方で、役割や部品が増えるという代償もあります。目的はパターンを使うことではなく、想定する変更を必要な範囲で実現することです。変更しやすさを重視する理由は、良い設計より「変更できる設計」が重要な理由で説明しています。
GoFデザインパターンの3つの分類
デザインパターンとして広く知られているのが、GoF（Gang of Four）が整理した23のオブジェクト指向デザインパターンです。GoFのパターンは、解決する目的によって生成・構造・振る舞いの3種類に分類されます。
| 分類 | 主に扱う問題 | 代表例 |
|---|---|---|
| 生成 | オブジェクトの作り方を利用側から分離する | Factory Method、Abstract Factory、Builder |
| 構造 | クラスやオブジェクトを組み合わせて新しい役割を作る | Adapter、Decorator、Facade |
| 振る舞い | 処理の分担や、オブジェクト間の連携方法を整理する | Strategy、Observer、State |
この分類は、候補を探すための入口です。生成パターンが必要か、振る舞いパターンが必要かを先に決めるのではなく、変化する部分、安定させたい部分、守るべき制約を明確にしてから、似た問題を扱うパターンを探します。
SOLID原則とデザインパターンの違い
SOLID原則とデザインパターンは、どちらも変更しやすい設計を考えるために使いますが、役割が異なります。
| 項目 | SOLID原則 | デザインパターン |
|---|---|---|
| 役割 | 責務や依存関係を考える判断原則 | 繰り返し現れる問題に対する解決構造 |
| 主な問い | 変更理由や依存方向は適切か | どの役割と協調関係で問題を解くか |
| 使い方 | 設計の問題を確認する | 問題に合う解決候補を比較する |
SOLID原則は、設計を確認する観点を示します。デザインパターンは、確認した問題を解く構造の候補を示します。両者は一対一に対応するものではなく、パターンを適用した後も責務や依存関係を確認する必要があります。5つの判断原則は、SOLID原則とは？5つの原則と設計での使い方をわかりやすく解説で整理しています。
送料計算へStrategyパターンを使う例
注文処理が、通常配送、冷蔵配送、大型配送の送料を条件分岐で直接計算しているとします。配送方法が増えるたびに注文処理を修正し、方法ごとの計算条件まで注文処理が知る状態では、送料の変更が注文処理全体へ波及します。
この問題では、「送料を計算する」という共通の役割を定め、配送方法ごとの計算を別の実装へ分けられます。注文処理は選択された計算方法へ注文情報を渡し、送料を受け取るだけです。交換可能な処理を同じ役割として扱い、利用側から切り替えられるようにするのがStrategy（ストラテジー）パターンの考え方です。
この構造にすると、新しい配送方法を追加しやすくなる一方で、どの計算方法を選ぶかを管理する必要が生じます。配送方法が増えない単純な処理なら、条件分岐のままの方が分かりやすい場合もあります。パターン名ではなく、追加される柔軟性が複雑さに見合うかで判断します。
デザインパターンの使い方
デザインパターンは、次の順序で検討します。
- 実際に起きている問題と、想定する変更を一つに絞る
- 変化する部分、安定させたい部分、制約を整理する
- 単純な設計と、候補となるパターンの効果・代償を比較する
- 必要な境界だけを実装し、変更時に結果を再確認する
最初から「どのパターンを使うか」を考えると、問題に合わない構造を作りやすくなります。既存の設計で対応できない理由が明確になった段階で、パターンを候補として使います。適用後は、役割がまとまり、不要な依存が減ったかを、凝集度と結合度の違いの観点でも確認します。
デザインパターンを使うときの注意点
- パターン名から設計を始めない：先に問題と変更の方向を明確にします。
- 書籍の構造をそのまま写さない：役割を保ちながら、実際の文脈へ合わせます。
- 将来の可能性だけで抽象化しない：起こり得る変更と影響の大きさを確認します。
- 利点だけで判断しない：部品数、生成方法、処理の追跡など、増える複雑さも比較します。
GoFの23種類をすべて使ったり、暗記したりする必要はありません。名前よりも、どの文脈で何の問題を解き、どのような結果を生むパターンなのかを理解することが重要です。
まとめ
デザインパターンとは、特定の文脈で繰り返し現れる設計問題と、その解決構造、適用結果を整理したものです。GoFのパターンは、目的によって生成・構造・振る舞いの3種類に分類されます。
設計では、パターン名から構造を決めるのではなく、まず変更したい内容と影響範囲を明確にします。そのうえで、問題に合うパターンを解決候補として選び、得られる柔軟性と増える複雑さを比較します。
関連記事
- SOLID原則とは？5つの原則と設計での使い方をわかりやすく解説
- 良い設計より「変更できる設計」が重要な理由
- 凝集度と結合度の違い｜高凝集・低結合が望ましい理由と判断方法
- 共通化とは？「とりあえず共通化」が設計を壊す理由を解説
コメント