デザインパターン
ソフトウェア設計で繰り返し現れる問題に対する再利用可能な解決策のカタログ
設計設計パターン
デザインパターンとは
デザインパターンは、GoF (Gang of Four) が 1994 年に「Design Patterns」で体系化した、ソフトウェア設計で繰り返し現れる問題に対する再利用可能な解決策のカタログである。23 のパターンが 3 カテゴリに分類される。
3 つのカテゴリ
| カテゴリ | 目的 | 代表的なパターン |
|---|---|---|
| 生成 (Creational) | オブジェクトの生成方法 | Factory, Builder, Singleton |
| 構造 (Structural) | オブジェクトの構成 | Adapter, Proxy, Decorator |
| 振る舞い (Behavioral) | オブジェクト間の連携 | Observer, Strategy, Iterator |
現代の開発でよく使うパターン
| パターン | 用途 | TypeScript での例 |
|---|---|---|
| Strategy | アルゴリズムの切り替え | 認証方式の切り替え |
| Observer | イベント通知 | EventEmitter, React の状態管理 |
| Factory | オブジェクト生成の抽象化 | DB クライアントの生成 |
| Builder | 複雑なオブジェクトの段階的構築 | クエリビルダー |
| Adapter | インターフェースの変換 | 外部 API のラッパー |
| Decorator | 機能の動的追加 | ログ、キャッシュの追加 |
Strategy パターン
interface PaymentStrategy {
pay(amount: number): Promise<void>;
}
class CreditCardPayment implements PaymentStrategy {
async pay(amount: number) { /* クレジットカード決済 */ }
}
class BankTransferPayment implements PaymentStrategy {
async pay(amount: number) { /* 銀行振込 */ }
}
// 実行時に戦略を切り替え
async function processPayment(strategy: PaymentStrategy, amount: number) {
await strategy.pay(amount);
}
AWS でのパターン
| パターン | AWS での実装 |
|---|---|
| Observer | SNS (Pub/Sub), EventBridge |
| Strategy | Lambda の環境変数で処理を切り替え |
| Adapter | Lambda が外部 API を DynamoDB 形式に変換 |
| Proxy | API Gateway (認証、スロットリング) |
パターンの過剰適用に注意
パターンは問題を解決するためのツールであり、全てのコードにパターンを適用する必要はない。YAGNI 原則に従い、必要になってから適用する。
❌ 「Factory パターンを使おう」→ 生成するクラスが 1 つしかない
✅ 「生成するクラスが 3 種類に増えた」→ Factory パターンを導入
体系的に学ぶなら関連書籍を参照してほしい。