ここまでの7回で、4つのデザインパターンを導入してきました。
- Command: 行動をオブジェクトとしてカプセル化
- State: 戦闘フェーズを状態として管理
- Strategy: 敵のAIアルゴリズムを交換可能に
- Observer: イベントを購読者に自動通知
今回は、これらのパターンがどのように連携して戦闘システムを構成しているかを俯瞰します。

パターン間の関係図
flowchart TB
subgraph Context["BattleContext"]
State["State\n(戦闘フェーズ)"]
Subject["Subject\n(イベント発行)"]
end
subgraph States["戦闘状態"]
Start["BattleStartState"]
PlayerTurn["PlayerTurnState"]
EnemyTurn["EnemyTurnState"]
End["BattleEndState"]
end
subgraph Commands["行動コマンド"]
Attack["AttackCommand"]
Defend["DefendCommand"]
Item["ItemCommand"]
end
subgraph Strategies["AI戦略"]
Aggressive["AggressiveAI"]
Defensive["DefensiveAI"]
end
subgraph Observers["イベント購読者"]
Logger["BattleLogger"]
Effect["DamageEffect"]
Reward["BattleReward"]
end
State --> States
PlayerTurn --> Commands
EnemyTurn --> Strategies
Strategies --> Commands
Commands --> Subject
Subject --> Observers
処理の流れ
戦闘が進行する際、各パターンは以下のように連携します。
- BattleContextが
BattleStartStateに遷移(State) PlayerTurnStateでプレイヤーがCommandを選択・実行(Command)EnemyTurnStateでAI戦略がCommandを決定・実行(Strategy + Command)- ダメージ発生時にイベントを通知(Observer)
- 勝敗が決まると
BattleEndStateに遷移(State)
シーケンス図
sequenceDiagram
participant PS as PlayerTurnState
participant AC as AttackCommand
participant E as Enemy
participant BC as BattleContext
participant O as Observers
PS->>AC: execute()
AC->>E: take_damage(15)
E->>BC: notify('damage_taken')
BC->>O: update('damage_taken')
AC-->>PS: 攻撃完了
PS->>E: is_alive?
E-->>PS: false
PS->>BC: change_state(BattleEndState)
各パターンの責務
| パターン | 責務 | 例 |
|---|---|---|
| State | 戦闘フェーズの管理と遷移 | 開始→プレイヤー→敵→終了 |
| Command | 行動のカプセル化と実行 | 攻撃、防御、アイテム |
| Strategy | AIアルゴリズムの選択 | 攻撃的、防御的 |
| Observer | イベントの通知と処理 | ログ、エフェクト、報酬 |
パターンを組み合わせるメリット
関心の分離
各パターンが異なる責務を担当しているため、コードが整理されています。
拡張性
新しい機能を追加するとき、既存のコードをほとんど変更せずに済みます。
- 新しい行動? → 新しいCommandクラスを追加
- 新しいAI? → 新しいStrategyクラスを追加
- 新しいイベント処理? → 新しいObserverクラスを追加
テスト容易性
各コンポーネントを独立してテストできます。
| |
統合コード(簡略版)
4つのパターンがどのように連携するかを示す簡略版コードです。
| |
この簡略版では、各パターンが最小限のコードでどのように協調するかを示しています。実際の完成版は次回(第9回)で紹介します。
今回のポイント
- State→Command→Strategy→Observerの連携を確認
- 各パターンが異なる責務を担い、関心が分離されている
- 新機能の追加が既存コードに影響しにくい設計
- 各コンポーネントを独立してテスト可能
次回は、これまでの成果を統合して対話型のバトルシステムを完成させます。
前回:
次回:
