Single handler vs multiple handlers for the Command Pattern

Question

I'll be soon implementing for the first time a Command pattern to catch general events about the world of the game I'm developing

Since I haven't found much info about this particular issue, I'm asking if it makes more sense to have a single 'catch-all' class which will eventually process any type of event or to offload events to different types of Queue

e.g. player related Commands will be offloaded to the Player class, enemies related commands will be offloaded to the Enemies class, and world/terrain related commands (such as chunk creation) will be handled by WorldGen

Normally, this would break the idea of having a 'receiver' object as a constructor parameter of an instance of a Command, but does having just a single 'catch-all' class more maintainable than partitioning the command handlers?

Is it maintainable in a convoluted game to have just a single catch-all class to execute every type of Command? Wouldn't it be easier to optimize the usage of more threads by having different command handlers?

Answer 1

A single handler would have a lot of dependencies, where as multiple handlers can be better compartmentalized.

Personally, I take it one step further, and make the handlers non-exclusive: events may have zero, one or multiple handlers listening for it.

If you make a system where handlers can subscribe to messages, then a single event (e.g. a hand-grenade going off) can generate responses from different parts of the game.

• The sound system may catch that event, and play a loud boom.

• A damage system may catch it and look for damaged players.

• A particle system may catch it and generate a flash and smoke.

• The leaderboard/achievement system may catch it, and unlock the achievement "Grenade"

• etc.

Set it up so that the event-generator does not need to know about any subscribers. The event is just generated. How many listeners there are, if any, is of no concern to the code that generated the event.

This creates nice code with few dependencies, because the code where a grenade is made to explode, does not have to depend on particle-system code, sound-code, or any other code that gets triggered via one or more handlers.

Because subscriptions are optional, it also means that if, for instance in debug runs, a system is not brought up, everything still keeps working. There are just fewer handlers listening to the event. You can run without the leaderboard-achievement system, or without the sound system, and nothing would break when a grenade explodes.