Мне он показался чрезмерно переусложнённым, к тому же его подход приводит к жуткой непонятной лапше. Я сделал свой компактный автомат на объектах с ключевой идеей: состояние есть объект, переходами являются ссылки между ними в виде свойств, этот граф можно распечатать в Dot нотацию и получить визуализацию.
Здравствуйте, hardcase, Вы писали:
H>состояние есть объект, переходами являются ссылки между ними в виде свойств, этот граф можно распечатать в Dot нотацию и получить визуализацию.
Означает ли это, что экземпляры состояний и весь граф фиксированы заранее на всё время жизни автомата?
Что если у состояния должно быть своё заранее не фиксированное состояние?
Например:
Отличие машины состояний от конечного автомата в том, что в машине число состояний потенциально бесконечное. Скажем MovingState — это бесконечное семейство состояний, параметризующихся значением velocity. На этот параметр влияют входные события/триггеры автомата, и сам этот параметр влияет на целевые состояния при переходах по входным событиям/триггерам. Кроме этого на целевые состояния при переходах влияет неявное и переменчивое состояние внешнего мира.
Здравствуйте, Qbit86, Вы писали:
Q>Означает ли это, что экземпляры состояний и весь граф фиксированы заранее на всё время жизни автомата? Q>Что если у состояния должно быть своё заранее не фиксированное состояние?
В моей задаче граф в целом известен заранее: это некоторый workflow с диалогами через который проходит пользователь, на некоторых этапах происходит взаимодействие с сервисами в интернете. Показ диалога — объект-состояние, ответ пользователя приведёт к следующему переходу, запрос в интернет — тоже объект-состояние, ответ сервиса приведёт к другому переходу. При переходах можно следующему объекту передавать данные, если это требуется.