State — поведение объекта зависит от его текущего состояния

State позволяет объекту менять свое поведение в зависимости от состояния, не используя громоздкие конструкции if/else или switch. Каждое состояние оформляется как отдельный класс, а объект делегирует ему выполнение логики.

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

State часто применяется в workflow, жизненных циклах сущностей, платежах, статусах заказов, процессах согласования, протоколах и машинных моделях.

Паттерн State — один из самых архитектурно значимых, потому что большинство бизнес-объектов в корпоративных ИС существуют в состояниях.
Заказ может быть:

• создан;

• проверен;

• оплачен;

• отменен;

• доставлен.

Документ может быть:

• черновик;

• на согласовании;

• отклонён;

• утверждён;

• архивирован.

Любой жизненный цикл — это автомат состояний. State помогает проектировать эти автоматы правильно.

Задача State

State решает проблему, когда объект:

• имеет множество состояний;

• выполняет разные действия в зависимости от состояния;

• может изменять своё состояние во время работы;

• имеет сложные переходы.

Без паттерна код превращается в чудовище:

perl
if state == CREATED:
    ...
elif state == CONFIRMED:
    ...
elif state == PAID:
    ...
elif state == CANCELLED:
    ...

State заменяет эту конструкцию самостоятельными классами.

Как работает State

1. Выделяется интерфейс State

Он определяет возможные действия.

css
OrderState:
    pay()
    cancel()
    ship()

2. Для каждого состояния создаётся свой класс

Например:

nginx
CreatedState
PaidState
ShippedState
CancelledState

3. Объект хранит ссылку на текущее состояние

А состояние знает, какой переход возможен.

4. Переходы осуществляются внутри самих состояний

Это главное отличие от Strategy.

5. Объект меняет своё состояние

Например:

vbnet
order.setState(new PaidState(order))

Где State применяется в архитектуре

1. Управление жизненными циклами

• заказов;

• документов;

• заявок;

• задач;

• проектов;

• процессов;

• билетов.

В корпоративных системах это встречается повсеместно.

2. Workflow и BPM

State часто является «ручной» реализацией простого workflow-движка.

Используется в:

• BPM-системах;

• микросервисах обработки событий;

• системах согласования.

3. Платежные процессы

Платежи проходят через множество состояний:

• инициирован;

• проверен;

• захвачен;

• подтвержден;

• отменен;

• частично возвращен.

State идеально ложится на такие модели.

4. Коммуникационные протоколы

TCP, HTTP, WebSocket — все протоколы имеют состояния.

Нельзя отправить данные до установления соединения.
Нельзя читать тело после функции закрытия канала.

State делает такие протоколы понятными и формальными.

5. UI и конечные автоматы

В UI активные элементы меняют поведение в зависимости от состояния:

• disabled;

• active;

• hovered;

• loading;

• error.

Большинство UI-фреймворков используют State-моделирование.

Преимущества State

• избавляет от гигантских конструкций if/else;

• делает модель простого или сложного автомата явной;

• переносит логику переходов внутрь состояний;

• облегчает расширение за счёт добавления новых состояний;

• повышает тестируемость;

• делает систему читаемой и формальной.

Недостатки

• увеличивает количество классов;

• может показаться избыточным для простых моделей;

• требует внимательного проектирования переходов.

Однако при моделировании жизненных циклов — незаменим.

State vs Strategy — главное отличие

Несмотря на внешнее сходство, разница огромна:

Strategy

Выбор алгоритма — действие внешнее.
Стратегия не знает о других стратегиях.
Она не меняет саму стратегию.

State

Состояние знает, в какие состояния можно перейти.
Состояние меняет объект, переводя его в другое состояние.
Переходы определяются внутри состояния.

Strategy = выбор поведения.
State = модель жизненного цикла.

State в российских учебниках

State рассматривается:

• в теме автоматов;

• в моделировании жизненных циклов;

• в workflow;

• в UI-архитектурах;

• в проектировании процессов.

Особенно подчёркивается роль State в цифровых платформах.

Почему архитектор должен знать State

Потому что каждая корпоративная система имеет состояния:

• статусы;

• флаги;

• последовательности;

• жизненные циклы.

Если они не моделируются правильно — архитектура быстро деградирует.

State обеспечивает:

• формализм,

• управляемость,

• контроль,

• предсказуемость,

• удобство поддержки.

Это один из фундаментальных инструментов архитектора.