パターン比較レビュー
| パターン | 適用条件 | 強み | 注意点 | よく使うシーン |
|---|
Template Method | 処理の流れは共通・一部だけ差分あり | 型の統一・共通化しやすい | 継承に依存しがち | 保存処理、バッチなど |
Strategy | 処理の切り替えが主目的 | 柔軟性・テスト性 ◎ | 実装数が増えがち | 通知・演算ロジック |
Bridge | 拡張軸が複数ある | 抽象・実装の独立が可能 | 設計が複雑化しやすい | UI× 出力方式など |
Flyweight | 似た構造・状態の重複がある | 軽量化、メモリ節約 | 状態を外部管理する必要あり | アイコン、座席、文字など |
Prototype | テンプレートを元に差分だけ変えたい | 再利用・複製が容易 | 複製時の副作用に注意 | UI、通知、設定など |
まとめと選び方の指針
- 差分だけの実装にしたい →
Template Method
- 処理の切り替えを柔軟にしたい →
Strategy
- 拡張軸が複数ある →
Bridge
- 同じ構造の繰り返しを軽量にしたい →
Flyweight
- テンプレートの構造をベースに差分で使いたい →
Prototype
実際の設計会話での使い分けヒント
- この共通処理に混ざってる '差分' は、
Template Method でフック化できそうですね
- この処理、
Template Method にすれば差分だけ実装できますよ
- 振る舞いを柔軟に切り替えたいなら、
Strategy にするのがいいかも
- 可変処理を
Strategy に切り出せば、動的に切り替え可能ですね
- これは通知方法と内容がそれぞれに変わるから、
Bridge で軸を分けて設計しましょう
- 構造が 2 軸で分かれてるなら、
Bridge で分離すると見通しがよくなります
- 同じアイコンをいくつも生成してるなら
Flyweight で共有できます
- この通知構造、
Prototype で clone して使い回すといいかもしれません