The Command Pattern: A Tale from the Guild of Actions

The Guild of Buttons

In the bustling city of Appington, the Guild of Buttons controlled every switch, click, and tap across the land. But something was dreadfully wrong.

The buttons all looked alike — yet each one did something completely different. Copy… Paste… Save… Undo…

Their inscriptions were unclear, and their powers tightly intertwined with unpredictable magic.

“Where does this button send its command?”

“Why must every guild master rewrite the same spell for paste?”

Such confusion threatened to collapse the harmony of the whole app.

Too Many Spellbooks

At first, every button had its own spellbook — ancient, distinct, and endlessly duplicated.

Each time the master mage altered a spell, every button subclass had to be rewritten.

One day, while copying the CopyButton spell, a mage exclaimed:

“This approach is invalid! We’re duplicating the same incantations everywhere!”

And so began the search for a better solution.

The Wise Command Scroll

Deep within the Hall of Abstractions, the archivist uncovered an ancient scroll.

It wasn’t a spellbook for one button… but a Command Scroll that contained all information about an action — what to do, where, and how.

“Turn every request into an object,”

— The scroll whispered.

Thus was born the Command Pattern — a new magic of decoupling.

The Waiter’s Order

To explain the magic, the elders summoned a real-world tale:

You sit at a tavern. You give your order to the waiter.

Rather than telling the chef directly how to cook, the waiter writes your order — the command on parchment, gives it to the cook, and returns later with your meal.

Your request is neatly packaged, queued, and executed without repeated explanations — and with no dependency on who the cook is.

The Command Structure

The magic unfolded into five major rune classes:

1. Invoker (Sender) — The button that initiates a command.
2. Command — The spell object — all info about the request.
3. Concrete Commands — Specific actions like Copy, Paste, Cut.
4. Receiver — The engine that executes the action.
5. Client — The mold and binder of commands.

The invoker never touches the receiver directly anymore. It simply triggers the command to work its magic.

The Arsenal of Actions

From that day forward, every operation in the domain (Copy, Cut, Paste, Undo) was encapsulated as a standalone command scroll.

No rewriting. No coupling. Just neat command objects that could be reused anywhere: buttons, menus, hotkeys, queues, or even remote queues on distant servers.

The Undo Chronicle

But the real magic didn’t stop there…

These command objects were so rich with history that each one could be:

Executed… Filed into a history stack… Undone if needed.

At any time, an adventurer could travel back through the Chronicles of Command History and undo any action — because each command had preserved enough context.

A New Era of Flexibility

The kingdom rejoiced:

• Buttons were now identical shells with linked commands
• Menus, shortcuts, dialogs all triggered stored command objects
• Deferred execution, logging, batching, and remote scheduling became possible
• Undo and redo became standard practice
• Code was clean, decoupled, and future-ready

The old chaos of subclasses and intertwined logic faded into legend.