Implementing the command pattern in C# for undoable operations

Software systems that let users reverse their last action are often taken for granted until that feature disappears. The command pattern, one of the classic GoF behavioural patterns, provides an elegant way to model reversible behaviour in C# by turning each request into a self-contained object. Conference attendees who work on line-of-business tools, financial dashboards, or content editors will recognise the pattern's value: every operation carries both the means to perform itself and the means to roll itself back.

This piece walks through the design, the C# code, and the supporting history mechanism that lets an application undo and redo actions reliably. Along the way, examples are drawn from scenarios familiar to Australian developers: invoice editors used by Sydney accounting firms, telemetry dashboards maintained in Melbourne, and field-data capture tools deployed in regional Queensland.

Understanding the command pattern's core participants

The pattern decouples the object that issues a request from the object that knows how to execute it. Five participants collaborate: the Command interface declaring Execute and Undo methods; concrete command classes that bind a receiver to a set of actions; the receiver itself, which owns the business logic and state; the invoker, which asks the command to run and stores it for later reversal; and the client, which assembles everything together.

By representing each action as an object, you can queue, log, serialise, replay, or undo it without changing the invoker. This is precisely what undoable workflows demand. A common mental shortcut is to think of the command object as a thin envelope around a method call, but the envelope matters: it captures the receiver, the arguments, and the inverse operation, which together allow the action to be reversed cleanly even after the original execution context has long vanished.

For Australian teams building software subject to the Australian Privacy Principles, the pattern has another quiet benefit. Because each command is a discrete record of what was requested, who requested it, and when, an audit trail can be assembled from the command log itself rather than retrofitted onto the domain model.

Designing a small but realistic C# example

Consider a simple text editor that needs to support character insertions and deletions with undo support. A straightforward ICommand interface sets the contract.

public interface ICommand
{
    void Execute();
    void Undo();
}

Each concrete command stores the receiver (the editor), the character affected, and the inverse data needed to reverse the change. An InsertCommand, for instance, remembers the character and its index, then on Undo deletes exactly that character at exactly that location. A DeleteCommand remembers the character it removed and re-inserts it at the recorded position. The receiver stays ignorant of any command machinery and continues to expose only Append, RemoveAt, and Length methods.

The Invoker in this design is typically a stack-backed history manager. The application's user interface calls invoker.Run(command), which both calls Execute and pushes the command onto an undo stack. When the user presses Ctrl+Z, the invoker pops the top command, calls Undo, and pushes the command onto a redo stack. Ctrl+Y reverses the process. Because each command object carries everything needed to undo itself, the Invoker never has to know about the receiver's internal layout, which keeps coupling low.

A subtle but important detail in C# is the use of immutable snapshots inside commands. Storing the original character value rather than a reference to a mutable buffer ensures that undo remains correct even if the buffer is later reassigned. Many Australian software houses have learned this the hard way, particularly when integrating with legacy VB6 components still common in certain Commonwealth departments.

Storing and replaying command history

A naive history might simply keep a List<ICommand>, but that breaks down once redo enters the picture. The classic data structure is two stacks: undo and redo. Running a new command clears the redo stack, since the new action invalidates any future that was being built. Bounded stacks, such as a circular buffer of the last fifty actions, prevent memory bloat in long-running sessions like point-of-sale terminals in Brisbane retail outlets during end-of-financial-year rushes.

For more advanced scenarios, commands can be persisted to durable storage. Australian financial software operating under APRA's CPS 234 information-security standard often serialises command objects to an append-only log so that audits can reconstruct exactly which balance change happened, when, and by whose request. The same machinery also enables crash recovery: on startup, the application replays the log to bring state back to its last consistent point.

When commands need to be combined into a single reversible unit, a CompositeCommand wraps several ICommand instances and routes Execute and Undo to each child. This is particularly handy for multi-step forms, such as the GST-adjustment screens used during the Australian financial year closing in late June, where one user gesture must atomically adjust several ledgers.

Edge cases, testing, and integration with MVVM

Three edge cases repeatedly trip up developers. First, commands that fail partially must be designed so that Undo restores prior state even when Execute threw midway; a try/catch around the body, paired with compensating Undo logic, is the usual answer. Second, asynchronous commands introduce timing hazards; awaiting Execute and capturing the result before pushing onto the undo stack keeps the history consistent. Third, undo of an action that itself triggers another command (such as a macro) requires the macro to push its child commands as a single composite so that one Ctrl+Z reverses the whole sequence.

Testing undoable workflows benefits from property-based techniques: generate random command sequences, execute them, undo them all, and assert that the resulting state equals the initial state. This approach has become standard practice in Melbourne's fintech scene, where teams building budgeting apps for the Australian market must demonstrate that complex multi-account transfers revert cleanly.

In MVVM or Blazor applications, the Invoker is usually injected into a view-model, and the view-model exposes Undo and Redo methods that the UI binds to. Commands are constructed inside the view-model so they can capture references to observable properties, which is a cleaner alternative to passing them in from the code-behind. The pattern also composes well with the mediator and chain-of-responsibility patterns when a single gesture fans out to several subsystems.

Choosing between command, memento, and event sourcing

Several alternatives exist for reversible behaviour, each with trade-offs worth weighing.

For most line-of-business applications in Australia, the plain command-with-undo-stack approach is the right starting point. Add memento snapshots only when the inverse operation is genuinely difficult to author. Reach for event sourcing when regulatory drivers such as APRA prudential standards, the Australian Privacy Principles, or sector-specific record-keeping rules make a full audit log mandatory.

A few practical habits sharpen any implementation, and a few signals hint that an alternative pattern may suit a given module better.

Habits and signals worth keeping close

• Keep ICommand free of framework dependencies so commands remain unit-testable in isolation.
• Make Undo idempotent so repeated presses of Ctrl+Z after a single undo are safe.
• Bound the history stack to a sensible depth, then expose it for diagnostics.
• Use composite commands for any user gesture that touches more than one aggregate.

When to consider a different pattern:

• Switch to memento snapshots when inverse logic becomes harder to maintain than the snapshot itself.
• Switch to event sourcing when ATO-aligned audit retention exceeds a few years or cross-system reconciliation is required.
• Reach for a hybrid when command scope is wide and state is small enough to snapshot cheaply.

The command pattern rewards careful design with features that users expect and developers rarely think about until they are missing. A well-modelled undo history is one of the quieter signs of a mature C# codebase.