Что я понял из типичной реализации Шаблон состояния s таков:
Проблема: Представляет объект O , поведение которого изменяется в зависимости от его текущего состояния.
Решение:
1. Пусть S , другой объект внутри этого объекта O , представляет состояние
2. Объект S вызовет соответствующую операцию O
3. Объект S определит следующее состояние для объекта O
Меня больше всего беспокоит #3
. Таблица переходов между состояниями в основном распределена по всем состояниям. Я видел, что этими решениями стало очень трудно управлять очень быстро. Вместо того, чтобы быть индикатором, эти состояния содержат слишком много информации о конечном автомате.
Хотя #2
беспокоит меня, я думаю, что это вполне разумно ( Машина Мура .) Единственная проблема, с которой я столкнулся, возникает во время исправления ошибок / отладки: навигация / понимание кода становится трудной, пока один не фиксирует все состояние отображения в память.
Будет ли следующая реализация более точной?
Представлять состояния в виде перечислений, и объект решает действие на основе значения, содержащегося в перечислении. state transitions
находятся в таблице (δ, функция перехода состояния), которая является отображением текущего состояния в следующее состояние. Это state transition table
также содержит действие, которое должно быть выполнено ( Mealy machine )