パターン比較レビュー
| パターン | 適用条件 | 強み | 注意点 | よく使うシーン |
|---|
Facade | 複雑な処理をまとめたい | 外部に対して使いやすくなる | まとめすぎると責務が曖昧に | API、ドメイン層、サービス |
Strategy | 条件分岐やアルゴリズムを切り替えたい | 拡張性・テスト性 ◎ | 実装クラスが増える | 割引戦略、ソートアルゴリズムなど |
State | 状態ごとに処理が変わる | 状態遷移と処理を明示的に分離 | 状態が少ないと過剰設計に | フロー、UI、モード制御など |
Composite | 階層構造を持つデータを扱う | 再帰処理が簡潔、構造が柔軟 | 複雑な階層設計では管理に注意 | メニュー構造、組織図など |
Iterator | 自作コレクションの走査が必要 | 処理の統一・抽象化ができる | 単純配列なら過剰設計 | カスタム集合、ツリー走査など |
まとめと選び方の指針
- 1 つのクラスが大きくなりすぎたらまず疑う → God Object
- 責務を明確に分離し、小さなクラスに分割して整理することが大切
- 処理は
Facade や Strategy で分離
- 状態管理は
State で切り出し
- **構造（ツリー/階層）**は
Composite で整理
- **走査（リスト・ツリー）**は
Iterator で抽象化
- 単にメソッドが多いのではなく、「何が責務として肥大化しているか」に注目するのがポイント！
実際の設計会話での使い分けヒント
- このクラス、やること多すぎません？責務分けて Facade で整理しましょう
- 状態によって振る舞い変わってるから State パターンに切り出せそうです
- ここのロジック、切り替えられるように Strategy 使うとテストしやすくなりますよ
- この中にある階層構造、Composite にした方が再帰処理も見やすくなりそうですね
- 中の配列ループ、for 文直書き多くて読みにくいので Iterator 導入してみませんか？