Хороший дизайн, чтобы построить целую программу как FSM? - PullRequest
1 голос
/ 13 сентября 2010

Я создал парсер, используя подход FSM / Pushdown Automaton, как здесь (и он работает, хорошо!): C ++ FSM дизайн и владение Это позволяет мне корректно выйти и вывести полезное сообщение об ошибке пользователю, когда что-то идет не так на этапе синтаксического анализа.

Я задавался вопросом о хорошем способе сделать это в остальной части моей программы, и естественно, парсерный подход всплыл в моей голове ...

Я бы сделал каждый объект состоянием, в котором есть одна функция event (), в которой есть оператор switch, вызывающий специфические для объекта функции в зависимости от стадии выполнения, которой я являюсь. Я могу отследить это с помощью объектно-специфических перечислений и сделать код более читабельным (case parser более читабельно, чем case 5). Это позволит мне закрыть созданное мной дерево выпадающих меню (используя подход m_parent* в моем другом вопросе).

Это хороший дизайн (форсирование всего в режиме FSM)? Есть ли лучший способ и насколько он будет сложнее (я считаю, что FSM довольно прост в реализации и тестировании)?

Спасибо за предложения!

PS: я знаю, что в boost есть все, что может понадобиться, но я хочу ограничить внешние зависимости, особенно от boost. C ++ 0x в порядке (но я думаю, что это не совсем актуально)

Ответы [ 3 ]

1 голос
/ 13 сентября 2010

То, что вы делаете, немного похоже на создание (простой) виртуальной машины в вашей программе.FSM, как правило, хорошо подходит для некоторых ограниченных проблем, таких как лексизация и синтаксический анализ, и, как вы, вероятно, заметили, вы можете получить немало регистрации и управления ошибками «бесплатно».

Однако, если вы попытаетесь применить шаблон FSM ко всему (что будет непросто, например, для программ с графическим интерфейсом, которые содержат довольно много состояний, которые вы обычно не захотите переводить в явные состояния), выВы поймете, что вам также нужны средства для отладки вашего FSM (поскольку отладчик C ++ не будет понимать ваши состояния и события) и средства для связи и повторного использования состояний (так каксостояния не будут конструкциями уровня ОО).Если вы когда-нибудь захотите передать свой код кому-то другому, ему или ей потребуется дополнительное обучение для успешного использования вашего FSM.Собираетесь ли вы использовать один движок FSM для нескольких приложений?Если да, то как вы собираетесь работать с версиями и обновлениями?

Используйте правильный инструмент для правильной работы.Каждый подход имеет свои сильные и слабые стороны.Ваше решение добавляет еще один уровень сложности : вы можете работать с журналированием и обработкой ошибок несколькими способами C ++.Если вы недовольны написанием кода на C ++, вы можете рассмотреть другие существующие языки, а не создавать язык FSM, который понимаете только вы.

0 голосов
/ 13 сентября 2010

Вы всегда можете взглянуть на boost .

0 голосов
/ 13 сентября 2010

Большинство людей будут использовать наследование вместо switch / case / default. Тем не менее, идея заставить все быть в одном направлении по своей сути ошибочна. Вы всегда должны подходить к каждой требуемой функциональности по своим достоинствам.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...