More State Machine Love: From Reflection to Statecharts
In the article the author states:<p><pre><code>  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.
</code></pre>
I disagree with this a bit. I think that the state transitions are <i>not</i> part of the public interface -- they&#x27;re an implementation detail of the SM. The public interface of a SM are its states and the events it responds too. It&#x27;s up to the SM to decide when to do the transitions. (The _author_ of the SM would be very interested in it&#x27;s transition graph&#x2F;conditions of course.)<p>For example, reviewing a bunch of the javascript SM libraries I see a few have the SM define a &quot;transition table&quot;. This works for simple SM but makes it difficult to <i>conditionally</i> transition. Perhaps we want our bank account SM to automatically transition to the &quot;hold&quot; state if the balance goes below zero. With a fixed (i.e. as configuration) transition table we can&#x27;t do this (or we have to fight against the SM library, or the SM library has to be more complicated).<p>I guess I&#x27;m fairly influenced by this book:
<a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Practical-UML-Statecharts-Event-Driven-Programming&#x2F;dp&#x2F;0750687061" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Practical-UML-Statecharts-Event-Drive...</a>
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&#x2F;move states). Seems like something similar in javascript would be nice, except doing things in a javascript way.