Точно ли модель состояния представляет подход? - PullRequest
6 голосов
/ 07 марта 2011

Что я понял из типичной реализации Шаблон состояния s таков:

Проблема: Представляет объект O , поведение которого изменяется в зависимости от его текущего состояния.
Решение:
1. Пусть S , другой объект внутри этого объекта O , представляет состояние
2. Объект S вызовет соответствующую операцию O
3. Объект S определит следующее состояние для объекта O

Меня больше всего беспокоит #3. Таблица переходов между состояниями в основном распределена по всем состояниям. Я видел, что этими решениями стало очень трудно управлять очень быстро. Вместо того, чтобы быть индикатором, эти состояния содержат слишком много информации о конечном автомате.
Хотя #2 беспокоит меня, я думаю, что это вполне разумно ( Машина Мура .) Единственная проблема, с которой я столкнулся, возникает во время исправления ошибок / отладки: навигация / понимание кода становится трудной, пока один не фиксирует все состояние отображения в память.

Будет ли следующая реализация более точной?
Представлять состояния в виде перечислений, и объект решает действие на основе значения, содержащегося в перечислении. state transitions находятся в таблице (δ, функция перехода состояния), которая является отображением текущего состояния в следующее состояние. Это state transition table также содержит действие, которое должно быть выполнено ( Mealy machine )

1 Ответ

1 голос
/ 07 марта 2011

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

void SleepingState::alarm()
{
    kick_alarm_clock();
    set_state(new GrumpyState());
}

Мы выбрали наш вывод (kick_alarm_clock) на основе как состояния (SleepingState), так и события (alarm), что делает его машиной Мили.

Ваша альтернатива действительно действительна и популярна (и есть другие). Поскольку для реализации машинной логики достаточно нескольких подходов, решение принимается исходя из других соображений «дизайна» или личного вкуса. Причины, по которым можно предпочесть шаблон «Состояния», могут быть в том случае, если вы думаете, что будете часто добавлять новые состояния, или если некоторые состояния кажутся достаточно похожими, чтобы оправдать отношения наследования. Я склонен выбирать эстетику: я использую паттерн State только в том случае, если машина достаточно плотная - то есть для большинства пар {state, event} есть нетривиальные действия и переходы. Если машина довольно редкая, меня смущают все пустые методы.

...