The blame is being placed on the wrong thing. It's not the state graph model that is the issue, but modeling it with object oriented constructs. The article actually also agrees that the the concept is succinctly modeled with the state graph diagram, and yet the object oriented version is hard to understand [1].
It's like saying Hashmaps are hard to use, when using List operations to manipulate a map stored as a list of tuples.
What the author needs is a library that can model state graphs in a much more readable way. I developed a state graph library for JavaScript when creating a turn-based game [2], which helped clean up my code immensely. There also appears to be a fairly popular Python library, with a nice looking API [3].
There is nothing "object oriented" about the example, except for the fact that the code is in a class.
The "proper object oriented way" would be the State design pattern, using separate classes for each state and replacing the if/else with a virtual call, which I agree would be even more obfuscation of the control flow:
Yep! I completely agree, there is nothing object oriented about the example. So why use constructs meant for describing objected oriented code? Though, the fact that someone defined a pattern for designing state machines on top of object oriented constructs is interesting, thanks for bringing that up.
The other option is build a model for talking about state machines on top of Python's features (like decorators, meta classes, even coroutines!) than strict OOP to feel more like idiomatic Python, than say Java. And when someone has written the code already, I say why reinvent the wheel! :)
Classes are a way to encapsulate state, you don't have to use them together with oo. How else would you describe the example in python without using object oriented constructs? Global variables or passing around a dictionary with all the things set up in init?
A distraction from the main point, being: state graphs rock! And deserve a high level way of talking about them in any language of choice, which most languages don't include in the stdlib. So one may have to roll their own/find a library. And that the article confused code that's "difficult to understand" with state graphs being bad.
> Classes are a way to encapsulate state, you don't have to use them together with oo.
Lexical closures are another way to encapsulate state, modules are another, then there are monads! People have thought of lots of cool ways to encapsulate state.
> How else would you describe the example in python without using object oriented constructs? Global variables or passing around a dictionary with all the things set up in init?
I would build the example on state graph terminology, instead of on top of Python's class directly. Though, as userbinator pointed out, someone has described an OOP pattern for talking about state graphs [1].
Unfortunately there is no built in way for talking about state graphs in Python. To build that, Python has lots of fun features I can leverage! I wouldn't artificially limit myself. But first I would definitely research if someone has written a good library.
I recently found out you can even choose to define states using arbitrary objects/functions, eg. date ranges. Sounds a bit crazy but I can see it solving certain problems very neatly.
It's like saying Hashmaps are hard to use, when using List operations to manipulate a map stored as a list of tuples.
What the author needs is a library that can model state graphs in a much more readable way. I developed a state graph library for JavaScript when creating a turn-based game [2], which helped clean up my code immensely. There also appears to be a fairly popular Python library, with a nice looking API [3].
[1] "it’s generally difficult to understand what’s going on in the code without having some sort of a state diagram in front of your eyes." [2] https://github.com/munro/stategraph [3] https://github.com/jtushman/state_machine