Hi!
I have spend a couple days working with your State Machine, and I have to congratulate you on your code!
However, I have been unable to find a clean solution to one issue I have: I want to trigger and listen to State changes from non State classes.
I have this List of Commands, and each command knows which state to trigger. Since the method Execute of the State class is async and awaitable, it should be easy to simply iterate the list waiting for each State to finish before sending in the next one.
Right now, since changing a State is not possible unless from a Transition.GoTo or similar at the end of an Execute() from a State class, my solution involves a custom method at the end of the Execute to check what the next state should be. This currently involves Reflection and unwanted code from my end, and the biggest thing: States should not be in charge of choosing the next State with this approach.
The command list should be the one triggering the Execute methods, having the responsibility and allowing for better testing, and for that, having a reference to the StateMachine should suffice.
I don't know if there is an angle I haven't seen or if this is something that clashes with the way you plan to code your State Machine, but I wanted to reach out and see your point of view.
Thanks in advance for your response and, again, congratulations on your work!
Hi!
I have spend a couple days working with your State Machine, and I have to congratulate you on your code!
However, I have been unable to find a clean solution to one issue I have: I want to trigger and listen to State changes from non State classes.
I have this List of Commands, and each command knows which state to trigger. Since the method Execute of the State class is async and awaitable, it should be easy to simply iterate the list waiting for each State to finish before sending in the next one.
Right now, since changing a State is not possible unless from a Transition.GoTo or similar at the end of an Execute() from a State class, my solution involves a custom method at the end of the Execute to check what the next state should be. This currently involves Reflection and unwanted code from my end, and the biggest thing: States should not be in charge of choosing the next State with this approach.
The command list should be the one triggering the Execute methods, having the responsibility and allowing for better testing, and for that, having a reference to the StateMachine should suffice.
I don't know if there is an angle I haven't seen or if this is something that clashes with the way you plan to code your State Machine, but I wanted to reach out and see your point of view.
Thanks in advance for your response and, again, congratulations on your work!