У меня был бы класс «высокого уровня» State Machine
, который контролирует вход / запуск / выход каждого состояния (где состояниями могут быть такие вещи, как «заполнение», «стирка», «полоскание», «опорожнение», «всухую» и т. д.)
Составьте Диаграмму перехода состояний всех необходимых вам состояний, включая (для каждого состояния)
- какие требования существуют перед вводом состояния (условия входа)
- что должно произойти при вводе состояния (действия при вводе)
- что происходит во время состояния (сама задача)
- какие требования существуют, прежде чем вы сможете покинуть штат (условия выхода)
- что происходит при выходе из состояния (выход из действий)
Вам могут или не могут понадобиться условия входа / выхода (например, в некоторых случаях вы можете форсировать условия с помощью действия входа / выхода). Однако по соображениям безопасности некоторые условия могут быть хорошими (например, выход из состояния «ожидания» или переход в «опасное» состояние, такое как отжигание)
Вы также создаете Transitions
, который определяет связи между состояниями. Переход имеет
- a 'из' состояния
- а 'в' состояние
- условия перехода (возможен ли переход?
- переходные действия (что должно произойти при переходе)
Опять же, вам может не понадобиться все это, и во многих переходах будут указаны только состояния «из» и «в».
В обоих случаях старайтесь, чтобы каждый State
и Transition
был настолько простым, насколько это необходимо нуждается в (попробуйте поставить условия / действия там, где они имеют наибольшее значение, очевидно, есть потенциальная двойная их количество должно быть определено в State
и a Transition
из-за общего дизайна)
В этот момент должно быть совершенно очевидно, что вы можете создать довольно общий класс State
, который включает абстрактные / перегружаемые функции для всех этих вещей, а также для класса Transition
. Класс State Machine
может вызывать каждую из этих функций-членов по мере необходимости на основании запрошенных переходов.
Если вы сделаете его особенно универсальным, тогда States
и Transitions
можно зарегистрировать с помощью State Machine
во время строительства, или вы можете просто набрать State Machine
, чтобы содержать их все.
Затем вы можете запросить переходы либо из в пределах состояний (т. Е. Определенное состояние может знать, когда оно закончилось, и знать, в какое состояние перейти в следующий), либо у вас может быть внешний класс, который контролирует переходы состояний (тогда каждое состояние очень простое, просто заботится о своих собственных действиях, а внешний класс определяет порядок и время переходов).
По моему опыту с этими вещами, хорошая идея отделить логику высокого уровня преднамеренного порядка / времени каждого действия и логику низкого уровня реакции на какое-либо аппаратное событие (например, переход из состояния «заполнения», когда уровень воды достигнут).
Это действительно общий дизайн, и вы можете достичь абсолютно одинаковой функциональности множеством разных способов - редко есть одиночный правильный способ делать вещи ...