Комментарии 8
Также интересен опыт применения КА не только для автоматизации бизнес-процессов, а в других областях.
Почему же автоматы обходят стороной и/или изобретают велосипеды, превращая код в спагетти?
По-моему, тут дело в стереотипе: мол, автоматы — это что-то сложное из
теоретической математики и к реальной жизни не относится. А применять их
можно только в лексических анализаторах или еще чем-нибудь специфичном.
Ну вот про парсеры мой опыт прямо обратный.
В теории state-machine это что-то удобное простое и чуть-ли не формально доказуемо что верное.
На практике же быстрее написать и отладить какой-нибудь рекурсивный спуск (не говоря уже о библиотеках типа Parsec), чем просто на бумажке завершить расписывание state-machine для лексера и для парсера.
А уж какой неинтуитивный (спагетти?) код, перенасыщенный низкоуровневыми деталями получается, при реализации прямой КО - это надо один раз увидеть, чтобы мысли к ним возвращаться не было.
Да есть ещё ваниант: не впрямую реализовывать КО, а объеденить несколько веточек в коде, сделать пару улучшающих код оптимизаций....
В результате:
- код становится чуть лучше (но всё ещё уродливым)
- единственное преимущество - код отражает ровно state machine, без возможности неточностей (при оптимизации и с резании углов) мы теряем.
ПС
Единственное, где мне state-machine пригодилась - это при реализации специфических низкоуровневых примитивов синхронизации.
Вот там действительно внимательность нужна и учесть все варианты.
Правда подозреваю, что "правильное" решение взять какой-нибудь пакет для разработки протоколов, но мааааа-леньких. Ничего хорошего не нашёл.
Возможно вы в курсе, но нынче баловаться принято проворачиванием фарша в обратную сторону, process mining, когда граф переходов (и шанс направления) восстанавливают из данных
Спасибо за интересный пример применения fsm подхода Попробую реализовать его в VAOP
https://habr.com/ru/post/554014/
Сага о моделировании бизнес-процессов на базе конечного автомата (fsm)