5 ms·
This is mostly a description of state, not of state machines. Status, published, or paid fields on your objects have little to do with state machines if the co
by pacemkr 15y ago
This is mostly a description of state, not of state machines.
Status, published, or paid fields on your objects have little to do with state machines if the code is not written with assertions about the current state of the application. These fields are just... well plain state, and no machine.
One would learn more about state machines from looking at the Ruby gem that's linked to in the article: https://github.com/pluginaweek/state_machine https://github.com/pluginaweek/state_machine
- wvanbergen 15y agoMy post isn't meant as a description about state machines; I point to wikipedia for that. The Ruby gem also gives a very nice introduction indeed. However, the point I try to make is very much about state machines, because modelling state using a state machine, forces you to think about all possible state transitions. This will make it less likely that you application will get into an unexpected state. Also, keeping an audit trail is very much about state transitions, because the transitions describe the behavior of the system, not the state itself.
- lgeek 15y agoI've always thought that gem's a bit silly. It makes sense to think in terms of state machines, but to code them explicitly?
- pygy_ 15y agoYet another misteriously killed post, by someone who's not deadbanned: In [1] , fleitz [2] wrote Explicitly using a state machine often yields benefits in terms of reusability and clarity. The state machine pattern also works really well with async code where it quickly becomes unapparent what's going on. [1] http://news.ycombinator.com/item?id=2650347 http://news.ycombinator.com/item?id=2650347 [2] http://news.ycombinator.com/user?id=fleitz http://news.ycombinator.com/user?id=fleitz
- 6ren 15y agoWeird, that's one of the most insightful comment here. Why would it be killed?
- deleted 15y ago[deleted]
- fleitz 15y agoExplicitly using a state machine often yields benefits in terms of reusability and clarity. The state machine pattern also works really well with async code where it quickly becomes unapparent what's going on.
- Stormbringer 15y agoThe same can be said of any of the lesser patterns. People who turn _everything_ into a Singleton for instance. Or who want everything to be a Factory or a Command.