Command

Turning a request into an object, so it can be queued, logged or undone.

A method call is ephemeral โ€” it happens and it's gone. Command wraps the request in an object carrying the action and its arguments, and once a request is a value you can do things you can't do with a call: put it on a queue, retry it, log it, schedule it, hand it to a different thread, or keep it on a stack so it can be undone.

Undo is the reason it earns its keep, and the design decision is what each command stores. Keeping the inverse operation is compact but only works when the action is cleanly reversible. Keeping a snapshot of the prior state always works and costs memory. Most real editors mix the two, and the interesting interview follow-up is what happens to the redo stack when a new command is executed after an undo โ€” it gets discarded, because the future you'd redo into no longer exists.

It's how a UI ends up with one action bound to a button, a menu item and a keyboard shortcut without duplicating logic three times: all three hold the same command object. The cost is a class per action, which is heavy when the actions are trivial and you never intend to undo, queue or log any of them.

What they ask, and what to say

What does making a request into an object let you do?

Everything you can do with a value and not with a call โ€” queue it, retry it, log it, schedule it, send it elsewhere, or push it on a stack to undo later. The invoker stops needing to know what the request actually does.

Why they ask: The 'request as a value' framing is what makes the pattern click, and it generalises to queues and job systems.

How do you implement undo with Command?

Each command knows how to reverse itself, either by storing the inverse operation or a snapshot of the prior state, and executed commands go on a stack. Inverse is compact but needs a cleanly reversible action; snapshots always work and cost memory.

Why they ask: The obvious follow-up, and the trade-off between the two approaches is the substance of the answer.

After an undo, the user runs a new command. What happens to redo?

The redo stack is discarded. Redo replays the branch you undid, and executing something new creates a different branch โ€” keeping the old one would replay a future that no longer follows from the current state.

Why they ask: A sharp detail that separates people who've built undo from people who've described it.