Конечный шаблон машины - один истинный образец?

Можно ли улучшить весь код, когда-либо написанный, путем применения шаблона State Machine?

Я работал над проектом, который был массой ужасающего ужасного, багги, сломанного кода спагетти. Я скопировал пример Мартина Фаулера "State Machine" из этого блога и превратил всю кучу дерьма в серию утверждений. Буквально просто список состояний, событий, переходов и команд.

Я не могу поверить в трансформацию. Код теперь чист и работает. Конечно, я знал о государственных машинах раньше и даже реализовал их но в примере Мартина Фаулера разделение модели/конфигурации удивительно.

Это заставляет меня думать, что почти все, что я когда-либо делал, могло каким-то образом выиграть от этого подхода. Я хочу эту функциональность на всех используемых языках. Возможно, это даже должно быть функцией уровня языка.

Кто-нибудь думает, что это неправильно? Или у кого-то есть аналогичный опыт с другим шаблоном?

Ответ 1

Конечные автоматы (FSM) и, более конкретно, специфичные для домена языки (DSL) упрощают сопоставление проблемы с одним конкретным доменом решения, описывая решение на специализированном языке.

Ограничения шаблона State Machine заключаются в том, что он сам представляет собой язык программирования, но тот, для которого вам необходимо написать собственные инструменты для выполнения, тестирования и отладки; и тот, который должен знать любой сопровождающий. Вы переместили сложность своего кода в сложную конфигурацию FSM. Иногда это полезно, но, конечно, не повсеместно.

И так как любой компьютер фон Неймана сам по себе является FSM, то, безусловно, любая программа может быть переделана таким образом.

Ответ 2

Код спагетти никогда не будет правильным ответом. Шаблоны хороши при очистке кода спагетти, но просто иметь продуманный дизайн может достичь того же.

Что касается вопроса о состоянии машины: я лично считаю их очень полезными. Для публичного приложения, которое я создал, я реорганизовал использовать диаграмму состояний (которая, как я думаю, такая же, как государственная машина), и заметила преимущества, которые вы упомянули. Это действительно полезная абстракция, поскольку она позволяет отделить проблему обработки событий от отдельного компонента. При этом ошибки исчезают, потому что диаграмма состояний неявно знает, что пользователь может делать там, и поскольку события обрабатываются только в нужном месте, вы не можете действительно выполнить недопустимое действие. Кроме того, использование диаграммы состояния позволило мне упростить код, потому что я мог вытащить весь код обработки событий из того места, где он был, и поместить его туда, где он находится в одном месте, где он должен был быть - другими словами, другие компоненты weren сложный, также имея на них обработчики событий.

Картина стоит тысячи работ - вот проект, который я придумал:

При этом каждый, кто смотрит на него, точно знает, как приложение ведет себя на высоком уровне. Его трудно сломать, потому что, как я уже сказал, вы не можете попасть в недопустимое состояние, потому что обработчики событий точно контролируют, где вы можете идти; если вы можете получить недопустимое состояние, это ошибка реализации, которая легко исправляется. Кроме того, преимущества очистки кода огромны. Например, с диаграммой состояний, когда я вхожу в какое-либо приостановленное состояние, я могу делать такие вещи, как остановить часы, поместить маску на доску и т.д. Его несколько строк кода в одном месте - потому что когда я вхожу в подставку после паузы диаграмма проходит через родительское состояние. без statechart, мне пришлось бы делать этот код везде, где было обработано событие.

Я не знаю, нужна ли эта функция на уровне языка, но хорошо реализована инфраструктура.