In event-driven systems, the Command pattern's main advantage is turning actions into first-class objects, which decouples what triggers an event from what handles it. That separation is exactly what event-driven architectures need to stay flexible and extensible.
Key Points: • Encapsulating each action as a command object decouples event producers from the code that actually executes the action. • Commands can be queued, so events can be buffered and processed asynchronously rather than handled immediately. • Command objects make logging and auditing straightforward, since each one naturally records what action occurred. • Undo/redo becomes possible by storing executed commands and calling a corresponding reverse operation. • New event types can be added as new command classes without modifying the dispatcher or event loop.
Example: A UI event dispatcher can map button clicks to Command objects like SaveCommand or DeleteCommand, so adding a new button only requires a new command class, not changes to the dispatch logic.
Interview Tip: A concise interview answer is:
"Command decouples the event source from the handler by wrapping each action as an object, which lets an event-driven system queue, log, or undo actions instead of executing them inline and immediately. It also means new event types are just new command classes, with no changes needed to the dispatcher itself."