More State Machine Love: From Reflection to Statecharts
raganwald.com
raganwald.com
The way I wrote my code is I model the state machine and the states as separate objects and I model the transitions between states as events with messages that the states inform the state machine of and then the state machine looks at what is the current state and what is the current event and it looks at what state if any it should transition to as a result of this.
Here is the class for my state machine object: https://github.com/ctsrc/ITR-LotPT/blob/master/src/statechar...
And here is where I create states and register said states and their transitions with an instance of my state machine: https://github.com/ctsrc/ITR-LotPT/blob/master/src/main.js
Prior to reading about statecharts my state machines used to be messy and hard to reason about. The one I mentioned above feels very clean and I am very happy with it.
As you can see this state machine I use for transitioning from resource loading to main menu and then to the main game, as well as going between the in-game and paused states. For the main game itself I do not use a separate state machine because currently I feel that if I added that stuff there I would be adding overhead without much benefit. The game is still in an early stage and far from finished. The game is in fact not even playable yet. But like I said I feel good about that state machine of mine.
____
* https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
It's cute, in a "look at how I can make the language do this"/novelty way, but I don't think it's JavaScript's fault per se, as this seems similar to Java architects solving problems with "just another factory", "just another annotation", "just another bytecode generator", etc.
> Your typical architecture astronaut will take a fact like “Napster is a peer-to-peer service for downloading music” and ignore everything but the architecture, thinking it’s interesting because it’s peer to peer, completely missing the point that it’s interesting because you can type the name of a song and listen to it right away.
This sentence so succinctly summarizes the current "blockchain" craze that it's hard to believe he wrote it in 2001.
I haven't tried building a nested/hierarchical state-machine with it - mostly because I have been able to decompose my problems into units that didn't need them, but also because hierarchical state machines always give me a head-ache larger than deadline.
[1] https://github.com/jakesgordon/javascript-state-machine [2] https://gist.github.com/sramam/fba55f5325a8c398870292e1f3cad...
I'm happy that the ability to generate GraphViz drawings has already helped me find a bug, at design time!
In a language like Elm, you'd pattern-match on the current state every time. Is there a better way?
You might also want to know which actions are valid for UI purposes, but validating an action is more complicated than just checking the current state. For example, a withdrawal action may or may not be valid depending on the amount.
That said, a withdrawFunds action shouldn’t be available if the user is in the loggedOut branch of the statechart
the top few comments i find compellingly skeptical.
The second is addressed with hierarchical state machines.
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.
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.
Conditional transitions, before- and after- actions, state entry conditions/validations, ... There are all sorts of places to go that have been proven fertile for developing robust software.
But you know... In one essay (two if you count its predecessor)... You have to draw the line somewhere. The goal is not to present a unified theory of modelling domain objects with state, nor is it to introduce some code that should be copied and pasted into a production pull request.
The simple goal is to provoke a conversation.
And if the outcome of that conversation for some people is, "We need conditional transitions, so the exact thing articulated in the essay is NoDamnGoodForUs," then I am actually quite satisfied that I've done my job as a blogger.
And if I can address your specific point--which I hope you understand that I agree with, even if it disagrees with that one paragraph--there are multiple approaches, and I think that if we really were modelling bank accounts as domain object with .deposit or .withdraw methods, we could do just as you suggest and bake a conditional transition to a Held state.
But we could also ask if the bank account is responsible for making that decision? In some architectures, we might say that this is burdening it with too much responsibility. I actually mulled this over with the following use case, which I decided to cut from the essay:
Consider a "suspicious deposit," or maybe a "suspicious transaction pattern," like a series of deposits and immediate withdrawals. PayPal is notorious for freezing accounts that violate some set of hidden rules.
Should the .deposit and .withdraw methods know about this and sometimes transition to "held?" One could argue this is not the account's responsibility, especially if some aspects of what makes a transaction suspicious involve things outside of the balance, like how long the customer has been with the institution.
Of course, there could be a line of code that calls a "Transaction Evaluator" thingummy from within the .deposit and .withdraw methods, or even a .validate method that always checks for this kind of thing after any action.
Or... Maybe this is a lot more like an MVC architecture, and the responsibility for checking the transaction falls to the controller, not the account model. So the controller calls .deposit or .withdraw, and the controller checks for suspicious transactions (or for negative balances), and the controller calls .placeHold on the account if necessary (and possibly on ALL accounts for the customer).
I'm not suggesting that this is superior to your suggestion, but it was something I thought about, and in some application architectures, I think what I just described is the way to do it. In others, what you described is the way to do it.
JM2C. Thanks for your comment.
Interestingly, that embedded device I made wound up being MVC without explicitly intending so -- the statecharts were the controllers. The only conditional transitions had to do with code reuse, where a single implementation lead to slightly different transitions depending on how it was configured.
This approach worked quite well for me at the time and still seems to have more clarity for high-level state management than the modern redux approach.
State machines are a natural fit for audit logging and replay, both issues that come up whenever your "models" go into production and customers report errors.