| >I really don't like state machines because if you need to add a new event, each of the states need to be updated to handle that event Depends but usually no. An event in a state which has no transition from it would be an error. The state becomes undefined and you produce a crash. >If you add a new state, you have to figure out how to handle each of the transitions from other states. Yes but only states that transition to this new state which is easily formalized. >Additionally, I find that I cannot understand how the program works without actually drawing out the state machine diagram if I come across it the first time, so there is a bit of a learning curve SM diagrams are fairly easy, they were mandatory course material in my second semester at university. >It's also a nightmare to test because of all of the states that need to be tested. In fact, the opposite is usually true. You can mathematically verify that your state machine will always behave exactly as expected or crash. The coffee machine won't dispense coffee and return the cash put in; the state machine in it does not allow it, even better, such a series of events becomes utterly impossible. Once the coffee has been dispensed, the machines has only one way forward: initial state. Additionally, SMs allow you to verify that your specific implementation is the most optimal one. And if it isn't, you can easily derive it. And you can test if two independent SM implementations are equivalent to eachother with 100% certainty. Sadly, since their state is very limited, they are usually not very useful once you want to do something that can't be expressed in a finite state machine (basically anything with threads, ever, to start with). |