Как вы, вероятно, прочитали, Шаблон проектирования состояний полезен, когда состояние изменяет поведение некоторого объекта, состав которого включает это состояние.Это подразумевает идею State абстрактного класса, интерфейса или перечислимого типа - хотя в зависимости от языка Duck Typing также подойдет - который определяет любое общее поведение и / илинеобходимые методы.
Ключевые аспекты
При работе с шаблоном состояния необходимо учитывать два ключевых аспекта: перечисление и переход.Перечисление просто означает идентификацию набора возможных состояний (например, дней недели) или, более абстрактно, типы состояний (то есть метасостояний), таких как начало, конец и между ними для механизма рабочего процесса. Переход означает решение, как моделировать движениемежду состояниями, где это обычно делается либо путем захвата всех возможных переходов в табличном представлении (то есть Finite State Machine ), либо сообщая каждому состоянию о своих возможных «переходах» в другие состояния.
Обычно переходы идут рука об руку с мета-состояниями, потому что невозможно заранее знать все состояния и отношения в такой динамической системе, где новые состояния и, следовательно, переходы могут быть добавлены во время выполнения.Кроме того, при переходном подходе определенное поведение - например, уведомления - становится частью перехода, а не самим состоянием.
Примеры
Есть несколько сценариев, над которыми я либо работал, либо обсуждал, где это средство использования:
- Рабочий процесс
- Компьютерная играAI оппонента
- Оркестровка процесса
Под рабочий процесс Я имею в виду что-то вроде jBPM .Системы, подобные этой, направлены на то, чтобы отдавать должное внимание нужным людям в нужное время.Они обычно отправляют много писем или каких-либо других уведомлений.И процесс, который они представляют, нуждается в способности меняться по мере изменения организации, тогда как управляемые данные обычно меняются гораздо медленнее.
Противник компьютерной игры AI говорит само за себя.Не то, что я написал, но в разговоре с теми, у кого есть, эти системы обычно самодостаточны.Другими словами, в отличие от рабочего процесса, в игре обычно нет возможности изменить процесс, используемый для управления компьютерными противниками.
Process Orchestration похож на рабочий процесс, но сосредоточен на системной интеграции, а не на взаимодействии с людьми.Примером является Apache Mule framework.Здесь состояние может описывать состояние (например, запущен, в процессе, закончен) и тип (например, точка интеграции ftp, точка интеграции sql).
Заключение
В отличие от других ответов, я считаю, что инкапсуляция состояний является отличным способом управления изменениями в программных системах.Хорошо выполненный, он облегчает эти изменения или позволяет пользователям делать это во время выполнения.Вы делаете компромисс между большей гибкостью в обмен на повышенную сложность реализации.Так что такой подход, вероятно, бесполезен, например, для корзины покупок, где поведение, вероятно, очень хорошо известно и не любит меняться.С другой стороны, когда процесс подвержен изменениям, он очень хорошо подходит.