Compare implementing an FSM as a switch statement versus a transition table.

A switch-on-state puts each state's logic in a case, with transitions as assignments to the state variable. It's readable, easy to debug (you can breakpoint a case), and handles rich per-transition logic naturally, best for small machines or ones with complex actions. A transition table encodes the machine as data: a 2D array indexed by [current_state][event] yielding the next state (and often an action function pointer). The whole behavior is one auditable matrix, it's compact, and you change behavior by editing a cell rather than control flow, best for large machines with many regular transitions, and it makes the machine easy to generate or verify. The tradeoffs: the table is less obvious to read for a tiny machine and awkward when transitions need bespoke logic that doesn't fit a uniform table cell; the switch grows unwieldy and error-prone when states and events multiply. So: switch for small/logic-heavy, table for large/regular, and the table is the dispatch-table pattern applied to states.