命令模式处理玩家动作的技术疑问：额外逻辑、调用与事件抛出

云上老周

2026-5-19

Hey there! Let's break down your questions about the Command Design Pattern in the context of your player action system (like your existing dice roll command) one by one:

1. Is it a reasonable approach to store additional business logic in commands?

The short answer is: it depends on what you mean by "additional."

Commands are designed to encapsulate a request and its associated logic, so directly related business logic is totally reasonable to include. For example, in your dice roll command, it makes sense to include logic like calculating the final roll value (accounting for player buffs, modifiers, or game rules like advantage/disadvantage) or validating if the player is allowed to roll right now (e.g., not in a cutscene, has enough action points).

Where you want to draw the line is when the logic is unrelated to the command's core purpose. If you start shoving in things like updating the player's inventory, triggering a quest completion, or handling UI popups directly in the dice roll command, you're violating the single responsibility principle. That makes the command bloated, hard to test, and difficult to reuse or modify later.

Stick to logic that's intrinsic to executing the command itself, and offload unrelated work to other services, handlers, or events (we'll talk about events in question 3!).

2. Can I directly call other commands from a dice roll command, or should I avoid this?

You can do it, but it's usually better to avoid direct calls unless you're using a composite command pattern intentionally.

Here's why:

Coupling issues: If your dice roll command directly instantiates and calls a MovePlayerCommand, you're tightly coupling the two. If you ever need to change how movement works (e.g., add a new movement type), you might have to modify the dice roll command too. That's a maintenance headache.
Undo/redo complexity: Commands often support undo/redo. If your dice roll command triggers other commands directly, tracking all those nested actions for undo becomes way more complicated. You'd have to manage a stack of all invoked commands instead of just the top-level one.

That said, there's a valid use case here: composite commands (or macro commands). For example, if rolling the dice is part of a larger TakeTurnCommand that also includes moving and attacking, you can create a composite command that executes all three in sequence. But even then, the composite command should be the one orchestrating the calls, not the individual dice roll command itself.

A better alternative to direct calls is using a command manager or event system to trigger subsequent commands. The dice roll command finishes its job, then tells the manager "I'm done—trigger the next step" or emits an event that the movement command listens for. This keeps your commands decoupled and flexible.

3. I think throwing events from commands is a better approach—Is this view reasonable?

Absolutely, this is a fantastic approach, and I'd argue it's one of the cleanest ways to extend your command-based system.

Here's why this works so well:

Decoupling: When your dice roll command emits a DiceRollCompleted event (with details like the roll value, player ID, etc.), it doesn't need to know what happens next. Any number of other systems—movement, quests, achievements, UI—can subscribe to this event and react independently. Want to add a new system that tracks roll streaks? Just subscribe to the event; no need to touch the dice roll command.
Flexibility: Events support multiple subscribers, so you can have multiple reactions to a single command execution without complicating the command itself.
Testability: Testing the dice roll command becomes simpler because you only need to verify that it executes its core logic and emits the correct event. You don't have to test all the downstream systems that react to it—those can be tested separately.
Maintainability: If you ever need to change how a downstream system reacts to a dice roll, you only modify that system's event handler, not the command itself.

The only caveat is to make sure your events are well-defined (carry all necessary data) and that you have a reliable event bus or dispatcher to manage subscriptions and emissions. But overall, this approach aligns perfectly with the command pattern's goals of encapsulation and flexibility.

内容的提问来源于stack exchange，提问作者Eren Williams