では、先ほどの フォールスルー switch と戦略パターンの処理フロー を比較した ASCII 図を作ります。
1. 元のフォールスルー switch の処理フロー
userType = "ADMIN"
┌───────────────┐
│ switch(userType) │
└───────────────┘
│
┌───────────────┐
│ case "ADMIN": │
└───────────────┘
│
notifyAdmin() ← ADMIN 特有の処理
│
▼ (breakなし!)
┌───────────────┐
│ case "USER": │
└───────────────┘
│
showMenu()
│
▼
┌───────────────┐
│ break / end │
└───────────────┘
💡 フォールスルーにより、ADMIN は notifyAdmin() → showMenu() と順番に実行される。
2. 戦略パターンでの処理フロー
userType = "ADMIN"
│
┌─────────────────────┐
│ UserFactory.getStrategy(userType) │
└─────────────────────┘
│
┌───────────────┐
│ AdminUser │
└───────────────┘
│
execute() 呼び出し
│
┌───────────────────┐
│ AdminUser.execute() 内で │
│ 1) notifyAdmin() │
│ 2) showMenu() │
└───────────────────┘
│
戻り値なし(処理終了)
💡 ポイント:
switchのフォールスルーは AdminUser.execute() 内でまとめる- Main では 単一の execute() 呼び出しだけで処理完了
- これにより、意図しないフォールスルーが発生する心配なし
比較のまとめ
| 観点 | フォールスルー switch | 戦略パターン |
|---|---|---|
| 可読性 | 処理の流れを理解するのに注意が必要 | 各クラスで処理を分離、直感的 |
| 拡張性 | 新しいユーザー追加は switch に case 追加 | 新しい戦略クラスを作るだけ |
| バグリスク | break の忘れで意図せぬ処理が走る | フォールスルーなし、意図が明確 |
| テスト容易性 | switch 文ごとにテスト | 各戦略クラスを単体テスト可能 |
