パターン比較レビュー
| パターン | 適用条件 | 強み | 注意点 | よく使うシーン |
|---|
Template Method | 共通処理の流れを固定したい | 型が決まり、差分が明確になる | 継承ベースなので柔軟性が低い | 保存処理、バッチ処理など |
Strategy | 処理の中身を切り替えたい | 柔軟性が高く、テストも容易 | 実装クラスが増えやすい | 通知処理、課金処理など |
Decorator | 追加処理を重ねたい | 組み合わせ可能で再利用性高い | ラップが多すぎると読みづらい | ログ、バリデーションなど |
Visitor | 複数の処理が必要 | 構造に手を加えず処理追加可能 | 拡張対象が多いと煩雑 | 出力形式、構文ツリー処理 |
Prototype | 似たような処理・構造を複製したい | 再利用・差分変更が容易 | clone() 実装に注意 | 設定、通知テンプレート、UI パーツ |
まとめと選び方の指針
- 似た処理が繰り返されている → まず
Template Method を検討
- 流れが共通で一部だけ異なる →
Template Method
- 処理の切り替えが主眼 →
Strategy
- 処理を「追加する形で重ねたい」 →
Decorator
- 処理とデータ構造を明確に分けたい →
Visitor
- オブジェクトそのものを複製して差分を持たせたい →
Prototype
実際の設計会話での使い分けヒント
- この処理、前のやつとほぼ同じなので
Template Method で差分だけ切り出しましょう
- 処理の中身だけ切り替えたいなら
Strategy にすると柔軟ですね
- ログ処理だけ重ねたいなら
Decorator でラップしましょう
- いろんな出力形式に対応するなら
Visitor で処理を分離した方が拡張しやすいですよ」
- 同じようなオブジェクトをちょっとずつ変えて使ってるなら
Prototype で clone するのが楽です