I. Command — Behavioral Pattern

The Command pattern encapsulates a request as a standalone object that contains all information needed to perform an action. This decouples the object that invokes the operation (the Invoker) from the one that knows how to perform it (the Receiver).

The key insight is that a command object acts as a bridge: instead of the Invoker calling a method directly on the Receiver, it calls Execute() on a Command object — which internally delegates to the Receiver. This indirection unlocks powerful capabilities: commands can be queued, logged, or undone, without the Invoker ever knowing the details.

This pattern is especially useful when you need to support undo/redo, transactional operations, or deferred execution — scenarios where a raw function call is simply not enough.

II. Real-world Example

Imagine a manufacturing line controlled by a remote controller. The remote can issue commands like "add wheels" or "paint the frame" — and it can also undo the last step if something goes wrong.

1. Receiver (ManufacturingContext) — knows how to assemble parts; maintains the current state of the vehicle being built.

2. Command interface (Command) — declares Execute() and Undo() methods that every command must implement.

3. ConcreteCommands (AddWheelsCommand, PaintFrameCommand) — each wraps a specific action on the ManufacturingContext and implements its own reversal logic.

4. Invoker (ManufacturingRemote) — holds a history of commands; calls Run() to execute and UndoLast() to reverse.

5. Client — wires everything together: creates the context, instantiates commands, and hands them to the remote.

III. Implementation

1// command.go
2package command
3
4type Command interface {
5	Execute() string
6	Undo() string
7}

1// manufacturing_commands.go
2package command
3
4import "strings"
5
6type ManufacturingContext struct {
7	parts []string
8}
9
10func NewManufacturingContext() *ManufacturingContext {
11	return &ManufacturingContext{}
12}
13
14func (c *ManufacturingContext) Snapshot() string {
15	return strings.Join(c.parts, ", ")
16}
17
18type AddWheelsCommand struct {
19	ctx *ManufacturingContext
20}
21
22func NewAddWheelsCommand(ctx *ManufacturingContext) *AddWheelsCommand {
23	return &AddWheelsCommand{ctx: ctx}
24}
25
26func (c *AddWheelsCommand) Execute() string {
27	c.ctx.parts = append(c.ctx.parts, "wheels")
28	return "Added wheels"
29}
30
31func (c *AddWheelsCommand) Undo() string {
32	if len(c.ctx.parts) == 0 {
33		return "Nothing to undo"
34	}
35	c.ctx.parts = c.ctx.parts[:len(c.ctx.parts)-1]
36	return "Removed wheels"
37}
38
39type PaintFrameCommand struct {
40	ctx *ManufacturingContext
41}
42
43func NewPaintFrameCommand(ctx *ManufacturingContext) *PaintFrameCommand {
44	return &PaintFrameCommand{ctx: ctx}
45}
46
47func (c *PaintFrameCommand) Execute() string {
48	c.ctx.parts = append(c.ctx.parts, "painted frame")
49	return "Painted frame"
50}
51
52func (c *PaintFrameCommand) Undo() string {
53	if len(c.ctx.parts) == 0 {
54		return "Nothing to undo"
55	}
56	c.ctx.parts = c.ctx.parts[:len(c.ctx.parts)-1]
57	return "Removed paint"
58}

1// manufacturing_remote.go
2package command
3
4type ManufacturingRemote struct {
5	history []Command
6}
7
8func NewManufacturingRemote() *ManufacturingRemote {
9	return &ManufacturingRemote{}
10}
11
12func (r *ManufacturingRemote) Run(command Command) string {
13	result := command.Execute()
14	r.history = append(r.history, command)
15	return result
16}
17
18func (r *ManufacturingRemote) UndoLast() string {
19	if len(r.history) == 0 {
20		return "No commands to undo"
21	}
22
23	last := r.history[len(r.history)-1]
24	r.history = r.history[:len(r.history)-1]
25	return last.Undo()
26}

IV. Explain the example above

Step 1 — Setup. The client creates a ManufacturingContext (receiver) and a ManufacturingRemote (invoker). It then instantiates two commands, each holding a reference to the same context.

1ctx    := NewManufacturingContext()     // parts: []
2remote := NewManufacturingRemote()      // history: []

Step 2 — Execute AddWheels. The remote calls Run(addWheels). Internally, Execute() appends "wheels" to ctx.parts and the command is pushed onto the history stack.

1remote.Run(addWheels)  // → "Added wheels"
2// ctx.parts = ["wheels"]
3// history   = [AddWheelsCommand]

Step 3 — Execute PaintFrame. Same pattern: Execute() appends "painted frame" and the command is recorded.

1remote.Run(paintFrame) // → "Painted frame"
2// ctx.parts = ["wheels", "painted frame"]
3// history   = [AddWheelsCommand, PaintFrameCommand]

Step 4 — Undo. The remote pops the last command from history and calls Undo() on it. PaintFrameCommand.Undo() slices the last element off ctx.parts.

1remote.UndoLast()      // → "Removed paint"
2// ctx.parts = ["wheels"]
3// history   = [AddWheelsCommand]

Step 5 — Undo again. Calling UndoLast() once more removes the wheels.

1remote.UndoLast()      // → "Removed wheels"
2// ctx.parts = []
3// history   = []

Notice that ManufacturingRemote never knows what "add wheels" or "paint" actually means — it just calls Execute() and Undo(). Adding a new operation (e.g., AssembleEngineCommand) requires zero changes to the remote.

V. Conclusion

The Command pattern shines when you need decoupling between who triggers an action and who performs it. The history stack makes undo/redo trivially composable, and commands can be serialized, queued, or batched without touching the Invoker.

However, it comes at a cost: every operation becomes a new struct, which can balloon the codebase when you have dozens of commands. In Go, closures often serve as lightweight commands for simple fire-and-forget scenarios — reach for the full pattern only when you genuinely need history, reversibility, or parametrized operations.

No pattern is universally superior.

VI. References

• Go Design Patterns (Mario Castro Contreras)

• Source code on GitHub