Where is the line between a state machines and object-oriented? One encapsulates some state and provides a set of messages to modify it. The other encapsulates some state and provides a set of transitions to change it.
The point of ""using a state machine"" is to make this explicit. Programs (and computers in general!) are already just ridiculously complex state machines. Issue is, however, that it is too complex to be reasoned about and so a simpler, explicit one on top is necessary
The last state machine I was involved with had to do with possible conditions when registering vehicles. What must be done if it was reported stolen (by NCIS) was coded in laws and regulations. What has to happen if the customer decides not to register it after all. Or they call up and go "hey! where's my title?" There were all sorts of edge cases that had to be unambiguously defined and documented. 99% of registrations followed the "happy path", but that last little bit caused all of the trouble. The printed version was an 11x17" flowchart with the "happy path" taking up less than 1/4 of it.
