I'm not sure about that book however this one: https://www.amazon.com/Practical-UML-Statecharts-Event-Drive...
got on my reading list by virtue of the misfortune of dealing with code written by programmers who adopted the book's approach.
The thesis was that state machines are a powerful formalism that can be fully verified because all the states and edges between them are known. That's half-right: they are powerful because state transitions are essentially "goto" by another name. In practice goto-based programming is brittle to requirement change. The damning part is that state machines don't live in isolation: they interact asynchronously with other state machines and the world at large. The dynamic behavior of these interactions is probably important! and not part of individual state machines. You'd need to co-simulate them.
I feel state machines have their place where no higher-level construct (usually I prefer coroutines) fits the job and it can be kept small and rewritten on requirement change.
From this, we get that accounts should certainly behave like state machines.
And from that, it’s reasonable that other pieces of code ought to be able to
dynamically inspect an account’s current state, as well as its complete graph
of states and transitions. That’s as much a part of its public interface as
any particular method.
I disagree with this a bit. I think that the state transitions are not part of the public interface -- they're an implementation detail of the SM. The public interface of a SM are its states and the events it responds too. It's up to the SM to decide when to do the transitions. (The _author_ of the SM would be very interested in it's transition graph/conditions of course.)
For example, reviewing a bunch of the javascript SM libraries I see a few have the SM define a "transition table". This works for simple SM but makes it difficult to conditionally transition. Perhaps we want our bank account SM to automatically transition to the "hold" state if the balance goes below zero. With a fixed (i.e. as configuration) transition table we can't do this (or we have to fight against the SM library, or the SM library has to be more complicated).
I guess I'm fairly influenced by this book:
https://www.amazon.com/Practical-UML-Statecharts-Event-Drive...
I found that approach worked very well when I used it to implement a fairly sophisticated UI on an embedded device. It was easy to rationalize about, easy to read in the code, and easy to maintain (add/move states). Seems like something similar in javascript would be nice, except doing things in a javascript way.
got on my reading list by virtue of the misfortune of dealing with code written by programmers who adopted the book's approach.
The thesis was that state machines are a powerful formalism that can be fully verified because all the states and edges between them are known. That's half-right: they are powerful because state transitions are essentially "goto" by another name. In practice goto-based programming is brittle to requirement change. The damning part is that state machines don't live in isolation: they interact asynchronously with other state machines and the world at large. The dynamic behavior of these interactions is probably important! and not part of individual state machines. You'd need to co-simulate them.
I feel state machines have their place where no higher-level construct (usually I prefer coroutines) fits the job and it can be kept small and rewritten on requirement change.
For example, reviewing a bunch of the javascript SM libraries I see a few have the SM define a "transition table". This works for simple SM but makes it difficult to conditionally transition. Perhaps we want our bank account SM to automatically transition to the "hold" state if the balance goes below zero. With a fixed (i.e. as configuration) transition table we can't do this (or we have to fight against the SM library, or the SM library has to be more complicated).
I guess I'm fairly influenced by this book: https://www.amazon.com/Practical-UML-Statecharts-Event-Drive... I found that approach worked very well when I used it to implement a fairly sophisticated UI on an embedded device. It was easy to rationalize about, easy to read in the code, and easy to maintain (add/move states). Seems like something similar in javascript would be nice, except doing things in a javascript way.
https://www.amazon.com/Practical-UML-Statecharts-Event-Drive...