Шаблон конечного автомата - единый истинный шаблон?

Question

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Картина стоит тысячи работ. Вот дизайн, который я придумал:

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

Я не знаю, должна ли это быть функция уровня языка, но хорошо реализованный фреймворк - это хорошо.