В мире разработки программного обеспечения управление состоянием объекта - одна из фундаментальных задач. Когда поведение объекта должно меняться в зависимости от его внутреннего состояния, разработчики часто обращаются к паттерну State. Однако здесь и возникает путаница: его нередко отождествляют с более общей концепцией — State Machine (Конечный автомат), а то и вовсе не видят разницы.

На самом деле, State — это лишь один из способов реализовать конечный автомат в ООП, и он прекрасен в своей простоте. Но что делать, когда логика усложняется, появляются асинхронные переходы, а количество состояний и событий растет? В этот момент простой паттерн State уступает место полноценным State Machine (FSM). А когда и их возможностей становится недостаточно для описания по-настоящему сложных систем с иерархией и параллельными процессами, на сцену выходят Statecharts.

В этой статье пройдем путь от простого к сложному:

• Разберем паттерн State как самостоятельную единицу и поймем, где его применять.

• Выясним, в какой момент его возможностей становится мало и на помощь приходит State Machine, рассмотрев практичную табличную реализацию.

• Наконец, доберемся до Statecharts и их реализации в Spring State Machine, которая позволяет элегантно управлять даже самой запутанной логикой состояний.

Погрузимся в мир управления состояниями — от простого к сложному!

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

State ≠ State Machine: разбираем поведенческий паттерн, который часто путают

State паттерн ("Состояние") — это поведенческий паттерн проектирования, который позволяет объекту изменять своё поведение в зависимости от внутреннего состояния. Многие описывают этот паттерн в контексте паттерна State Machine ("Конечный автомат", "Машина состояний") и не рассматривают в отрыве от этой концепции. На самом деле State самостоятельный паттерн и часто используется независимо.

Когда использовать State

Паттерн State особенно полезен когда:

• Логика поведения объекта зависит от его различных состояний.

• Логика содержит множество условных операторов (if/else, switch), зависящих от текущего состояния или внутренних флагов.

• Хотим убрать связь между состоянием и поведением.

• Есть множество состояний и они могут меняться со временем.

Примеры:

• Текстовый редактор с режимами: чтение, редактирование, навигация.

• Состояния заказа/платежа.

• Жизненный цикл кредита/займа.

• Транзакции между счетами.

• Активность пользовательского аккаунта.

Пример реализации на Java

Рассмотрим реализацию состояний текстового редактора.

Есть множество вариантов реализации паттерна State, некоторые из них могут нарушать принцип LSP(Liskov Substitution Principle), но тем не менее они представлены на множестве ресурсов. Рассмотрим вариант без нарушения принципа LSP:

Определяем интерфейс состояния:

public interface EditorState {
    void handle(TextEditor context);
}

Конкретные состояния реализуют интерфейс EditorState:

public class ReadingState implements EditorState {
    @Override
    public void handle(TextEditor context) {
        System.out.println("Вы находитесь в режиме чтения. Просматривайте документ.");
        System.out.println("Переход в режим редактирования.");
        context.setState(new EditingState());
    }
}

public class EditingState implements EditorState {
    @Override
    public void handle(TextEditor context) {
        System.out.println("Вы находитесь в режиме редактирования. Вносите изменения в текст.");
        System.out.println("Переход в режим навигации.");
        context.setState(new NavigatingState());
    }
}

public class NavigatingState implements EditorState {
    @Override
    public void handle(TextEditor context) {
        System.out.println("Вы находитесь в режиме навигации. Просматривайте разделы.");
        System.out.println("Переход в режим чтения.");
        context.setState(new ReadingState());
    }

}

Контекст, который хранит текущее состояние:

public class TextEditor {
    // Текущее состояние редактора
    private EditorState currentState;

    public TextEditor() {
        this.currentState = new EditingState(); // начальное состояние
    }

    public void setState(EditorState state) {
        this.currentState = state;
    }

    public void performAction() {
        currentState.handle(this);
    }
}

Тестирование:

public class Main
    public static void main(String[] args) {
        TextEditor editor = new TextEditor();

        // Цикл переключений состояний
        for (int i = 0; i < 3; i++) {
            editor.performAction();
            System.out.println("----------------------------");
        }
    }
}

Результат:

Вы находитесь в режиме редактирования. Вносите изменения в текст.
Переход в режим навигации.
----------------------------
Вы находитесь в режиме навигации. Просматривайте разделы.
Переход в режим чтения.
----------------------------
Вы находитесь в режиме чтения. Просматривайте документ.
Переход в режим редактирования.
----------------------------

Преимущества, которые мы получим, когда используем State

• Более чистый и структурированный код за счет применения Single Responsibility и Open-Closed принципов ООП.

• Уменьшается связанность между компонентами.

• Расширяемость - добавление нового состояния требует минимального изменения существующих.

• Инкапсуляция логики.

State Machine: когда State уже недостаточно

Паттерн State отлично подходит для управления поведением объекта в зависимости от его состояния. Но что делать, когда логика переходов между состояниями усложняется? Например в наших требованиях появляются:

• Множественные события перехода в одно состояние.

• Сложные условия перехода, зависящие от внешних факторов.

• Асинхронные переходы - например, ожидание ответа от API.

• Необходимость мониторинга и/или отката состояний (нужна история состояний).

• Динамическая конфигурация состояний - логика состояний должна быть гибкой и изменяемой без перекомпиляции кода.

В таких случаях подходящим решением будет использование - State Machine/Finite State Mashine (FSM - Конечный автомат).

История появления FSM

Идея конечного автомата (FSM) уходит корнями в математику и теорию автоматов 1940–1950-х годов. Она была описана в работах таких учёных, как Алан Тьюринг, Стивен Клини и Майкл Рабин, как модель вычислений.

В 1956 году — Джордж Мили и Эдвард Мур (не путать с Гордоном Муром из Intel) независимо друг от друга формализовали конечные автоматы (Finite State Machines, FSM):

• Автомат Мили — выход зависит от состояния и входа.

• Автомат Мура — выход зависит только от состояния. Эти модели стали основой для проектирования цифровых схем, компиляторов, сетевых протоколов и теории формальных языков.

FSM стали основой цифровой логики, компиляторов, сетевых протоколов и теории формальных языков.
Стоит отметить: В книге "Design Patterns: Elements of Reusable Object-Oriented Software" ("банды четырёх", GoF) описан паттерн State, но не State Machine/FSM.

Преимущества и недостатки State Machine

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

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

• Легко визуализировать (например, с помощью диаграмм состояний). Некоторые реализации FSM позволяют генерировать диаграммы по коду.

• Удобно использовать для отладки и логирования.

• Поддерживаются сложные переходы, события, действия и условные переходы.

• Хорошо масштабируется.

• Легко добавлять новые состояния и переходы, не затрагивая существующую логику состояний.

• Много готовых реализаций.

Недостатки:

• Требует больше кода и архитектурной подготовки.

• Может быть избыточна для простых сценариев.

• Реализация может быть очень громоздкой.

• Если машина состояний слишком большая, её сложно читать и отлаживать.

Интересная реализация State Machine - Табличная (Table-Driven) реализация

В этой реализации вместо отдельных классов для каждого состояния используется таблица (Map, но можно использовать и массив), которая хранит информацию о переходах состояний и связанных с ними действиях.

Сначала определим основы:

enum State {
    IDLE, PROCESSING, COMPLETED, ERROR
}

enum Event {
    START, SUCCESS, FAIL, RESET
}

interface StateHandler {
    void onEnter(State from, State to, Event event);
}

Теперь определим State Machine с таблицей переходов:

public class TableBasedStateMachine {
    private State currentState = State.IDLE;

    // Таблица переходов: event -> (от какого состояния -> в какое состояние)
    private static final Map<Event, Map<State, State>> transitions = Map.of(
            Event.START, Map.of(State.IDLE, State.PROCESSING),
            Event.SUCCESS, Map.of(State.PROCESSING, State.COMPLETED),
            Event.FAIL, Map.of(State.PROCESSING, State.ERROR),
            Event.RESET, Map.of(State.COMPLETED, State.IDLE, State.ERROR, State.IDLE));

    // Обработчики входа в состояние
    private static final Map<State, StateHandler> handlers = Map.of(
            State.IDLE, (from, to, event) -> System.out.println("Entered IDLE from " + from + " via " + event),
            State.PROCESSING, (from, to, event) -> System.out.println("Started processing..."),
            State.COMPLETED, (from, to, event) -> System.out.println("Processing completed successfully."),
            State.ERROR, (from, to, event) -> System.out.println("Error occurred during processing."));

    public void handle(Event event) {
        Map<State, State> stateMap = transitions.getOrDefault(event, Map.of());
        State nextState = stateMap.get(currentState);

        if (nextState != null && nextState != currentState) {
            State oldState = currentState;
            currentState = nextState;

            // Вызов обработчика входа в новое состояние
            StateHandler handler = handlers.getOrDefault(currentState, (f, t, e) -> {
            });
            handler.onEnter(oldState, currentState, event);

            System.out.println("Transition: " + oldState + " -> " + currentState);
        } else {
            System.out.println("No transition from " + currentState + " on " + event);
        }
    }

    public State getCurrentState() {
        return currentState;
    }
}

Тестирование и запуск:

public class Main {
    public static void main(String[] args) {
        TableBasedStateMachine sm = new TableBasedStateMachine();

        sm.handle(Event.START);      // IDLE -> PROCESSING
        sm.handle(Event.SUCCESS);    // PROCESSING -> COMPLETED
        sm.handle(Event.RESET);      // COMPLETED -> IDLE
        sm.handle(Event.FAIL);       // No transition
    }
}

Преимущества такого подхода:

• Наглядная таблица переходов — легко читать, расширить или загрузить из конфигурационных файлов (YAML/JSON).

• Изоляция разработчиков — легко тестируются и не захламляют переходную логику.

  • В отличие от классического switch, добавление нового состояния — просто расширение таблицы.

• Возможность использовать одну и ту же таблицу переходов, но разные обработчики.

Statechart и Spring State Machine: когда FSM уже недостаточно

Выше мы рассмотрели классические State Machine. Посмотрели на реализацию FSM с использованием таблиц. Но что делать, когда система разрастается и появляются такие требования:

• Вложенные (иерархические) состояния: состояние может иметь подсостояния, и переход из родительского состояния влияет на все его дочерние состояния.

• Параллельные (ортогональные) состояния: объект может находиться в нескольких независимых состояниях одновременно.

• История состояний: Возможность вернуться в последнее активное подсостояние после выхода из родительского состояния.

• Входные/выходные действия: действия, которые выполяются при входе или выходе из состояния.

• Визуализация сложной логики переходов: логика переходов становится настолько большой, что ее трудно понять, посмотрев код и требуется некоторая визуализация.

Здесь на помощь приходит Statechart — расширение FSM, предложенное Дэвидом Харелом в 1987 году. Он разработал их для моделирования сложных авиационных систем, где плоские FSM приводили к "взрыву состояний" и становились неуправляемыми. Ссылка на статью по Statechart (здесь немного модифицированная статья) - https://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.pdf. Здесь более подробно и с математическими выводами - https://is.ifmo.ru/works/pattern.pdf

Statechart: Эволюция конечных автоматов

Основная идея Statechart - добавление концепции иерархии (вложенных состояний), параллелизма и истории, что позволяет создавать более компактные и наглядные модели сложных систем.

Ключевые особенности Statechart:

• Вложенные состояния (Nested States): состояние может содержать другие состояния. Это позволяет группировать связанные состояния и упрощает диаграммы, так как переходы из родительского состояния применяются ко всем его дочерним состояниям.

• Параллельные состояния (Concurrent/Orthogonal States): состояние может быть разделено на несколько независимых ортогональных областей, каждая из которых имеет свой собственный конечный автомат. Это моделирует ситуации, когда объект одновременно выполняет несколько независимых функций.

• История (History Pseudo-States): позволяет автомату запоминать последнее активное подсостояние в составном состоянии, чтобы при повторном входе в него вернуться именно в это подсостояние.

• Entry/Exit Actions: действия, которые выполняются при входе в состояние или выходе из него.

• Internal Transitions: переходы, которые обрабатываются внутри состояния без выхода из него.

Statechart является частью UML (Unified Modeling Language), что делает его широко распространенным и понятным инструментом для моделирования поведения систем. Statechart идеально подходит для систем с множеством взаимосвязанных состояний, например, в workflow-движках или IoT-устройствах.

Spring State Machine: реализация Statechart на Java

Spring State Machine (SSM) — это фреймворк, предоставляющий реализацию концепции Statechart для Spring-приложений. Он предлагает декларативный подход к определению состояний и переходов, множество возможностей для гибкой настройки, интеграцию с другими Spring-проектами и многое другое.

Основные возможности Spring State Machine:

• Декларативное определение: состояния и переходы определяются с помощью конфигурации (Java-конфигурации или XML).

• Вложенные состояния: полная поддержка иерархических состояний.

• Параллельные состояния: возможность моделировать параллельные процессы.

• Действия (Actions): можно привязывать действия к переходам, входу/выходу из состояний.

• Условные переходы (Guards): условия, которые должны быть выполнены для осуществления перехода.

• События (Events): механизм для запуска переходов.

• Персистентность (Persistence): возможность сохранять и восстанавливать состояние конечного автомата (например, в БД).

• Мониторинг: интеграция с Spring Actuator для мониторинга состояния машины.

• Визуализация: можно определять состояния и переходы используя диаграммы состояний через eclipse Papyrus framework (к сожалению в 4 версии эту возможность удалили), вот тут описано как это сделать - https://docs.spring.io/spring-statemachine/docs/current/reference/#sm-papyrus.

Давайте рассмотрим пример использования Spring State Machine для сценария "обработки запроса", с более сложной логикой, включая вложенные состояния.

Обработка Запроса с Вложенными Состояниями

Пусть, наше состояние PROCESSING может быть детализировано на подсостояния: INITIALIZING, EXECUTING, FINALIZING. -

/ Перечисления для состояний и событий
enum States {
    IDLE,
    PROCESSING,
    PROCESSING_INITIALIZING,
    PROCESSING_EXECUTING,
    PROCESSING_FINALIZING,
    COMPLETED,
    ERROR
}

enum Events {
    START,
    INITIALIZE_DONE,
    EXECUTE_DONE,
    FINALIZE_DONE,
    SUCCESS,
    FAIL,
    RESET
}

Сама конфигурация StateMachine с логикой переходов между состояниями, условиями и вложенными состояниями будет выглядеть так:

@Configuration
@EnableStateMachine
public class RequestStateMachineConfig extends StateMachineConfigurerAdapter<States, Events> {

    @Override
    public void configure(StateMachineConfigurationConfigurer<States, Events> config) throws Exception {
        config
                .withConfiguration()
                .autoStartup(true)
                .listener(new StateMachineListener()); // Добавим слушателя для логирования
    }

    @Override
    public void configure(StateMachineStateConfigurer<States, Events> states) throws Exception {
        states
                .withStates()
                .initial(States.IDLE)
                .state(States.COMPLETED)
                .state(States.ERROR)
                .state(States.PROCESSING, processingActions()) // Действия для родительского состояния PROCESSING
                .end(States.COMPLETED) // Конечные состояния для ветки
                .end(States.ERROR)
                .and()
                .withStates()
                .parent(States.PROCESSING) // Определяем вложенные состояния
                .initial(States.PROCESSING_INITIALIZING)
                .state(States.PROCESSING_EXECUTING)
                .state(States.PROCESSING_FINALIZING);
    }

    @Override
    public void configure(StateMachineTransitionConfigurer<States, Events> transitions) throws Exception {
        transitions
                .withExternal()
                .source(States.IDLE).target(States.PROCESSING).event(Events.START)
                .action(startProcessingAction())
                .and()
                .withExternal()
                .source(States.PROCESSING_INITIALIZING).target(States.PROCESSING_EXECUTING)
                .event(Events.INITIALIZE_DONE)
                .action(initializeDoneAction())
                .and()
                .withExternal()
                .source(States.PROCESSING_EXECUTING).target(States.PROCESSING_FINALIZING).event(Events.EXECUTE_DONE)
                .action(executeDoneAction())
                .and()
                .withExternal()
                .source(States.PROCESSING_FINALIZING).target(States.COMPLETED).event(Events.FINALIZE_DONE)
                .action(finalizeDoneAction())
                .and()
                .withExternal()
                .source(States.PROCESSING).target(States.ERROR).event(Events.FAIL) // Переход из родительского состояния
                .action(failAction())
                .and()
                .withExternal()
                .source(States.COMPLETED).target(States.IDLE).event(Events.RESET)
                .action(resetAction())
                .and()
                .withExternal()
                .source(States.ERROR).target(States.IDLE).event(Events.RESET)
                .action(resetAction());
    }

    // Действия (Actions)
    public Action<States, Events> startProcessingAction() {
        return context -> System.out.println("Entering PROCESSING state from IDLE.");
    }

    public Action<States, Events> initializeDoneAction() {
        return context -> System.out.println("Processing: Initializing done. Moving to EXECUTING.");
    }
    // ....

    // Логирование состояний
    static class LoggingStateStateMachineListener
            extends StateMachineListenerAdapter<States, Events> {
        @Override
        public void stateChanged(State<States, Events> from, State<States, Events> to) {
            if (from != null) {
                System.out.println("Transition: " + from.getId() + " -> " + to.getId());
            } else {
                System.out.println("Initial state: " + to.getId());
            }
        }
    }
}

Проверить результаты работы можно через запуск:

@SpringBootApplication
public class SpringFsmDemoApplication implements CommandLineRunner {

	@Autowired
    private StateMachine<States, Events> stateMachine;

	public static void main(String[] args) {
		SpringApplication.run(SpringFsmDemoApplication.class, args);
	}

	@Override
	public void run(String... args) throws Exception {
		System.out.println("Current state: " + stateMachine.getState().getId());

        stateMachine.sendEvent(Events.START);
        System.out.println("Current state: " + stateMachine.getState().getId()); // Должно быть PROCESSING_INITIALIZING

        stateMachine.sendEvent(Events.INITIALIZE_DONE);
        System.out.println("Current state: " + stateMachine.getState().getId()); // Должно быть PROCESSING_EXECUTING

        stateMachine.sendEvent(Events.EXECUTE_DONE);
        System.out.println("Current state: " + stateMachine.getState().getId()); // Должно быть PROCESSING_FINALIZING

        stateMachine.sendEvent(Events.FINALIZE_DONE);
        System.out.println("Current state: " + stateMachine.getState().getId()); // Должно быть COMPLETED

        stateMachine.sendEvent(Events.RESET);
        System.out.println("Current state: " + stateMachine.getState().getId()); // Должно быть IDLE

	}
}

Полный код проекта доступен по ссылке.

Итоги

Выбор инструмента для управления состояниями напрямую зависит от масштаба задачи и сложности.

1. Паттерн State — отличный выбор, когда нужно инкапсулировать логику, зависящую от состояния, внутри объекта, избавляясь от громоздких условных операторов. Он прост, элегантен и идеально подходит для сценариев, где переходы между состояниями несложны и управляются самим объектом. Это отличная реализация принципов SOLID для локальных задач.

2. State Machine (FSM) — это следующий шаг, когда логика переходов становится явной и централизованной. FSM необходима, когда есть четко определенные события (events), вызывающие переходы.

3. Statecharts (и их реализация, например, Spring State Machine) — это решение для промышленных систем. Стоит использовать когда нужны:

   • Иерархические (вложенные) состояния для группировки логики.

   • Параллельные (ортогональные) состояния для моделирования независимых процессов.

   • История состояний, условные переходы (guards) и действия (actions).

Таблица с сравнением характеристик:

Spring State Machine предоставляет весь этот арсенал "из коробки", интегрируя его в экосистему Spring и добавляя персистентность, мониторинг и возможность визуализации (не во всех версиях).

Проще говоря, начинайте с State. Если переходы становятся сложными и требуют явного управления — переходите к State Machine. А если ваша система напоминает сложный производственный процесс - смело берите на вооружение Statecharts. Правильный выбор не только сделает ваш код чище, но и сэкономит массу времени на отладку и поддержку в будущем.

Управление состоянием — это не просто техническая задача, а философия проектирования. Правильно выбранный подход превращает хаотичную логику в четкую, тестируемую и документируемую систему. Помните: хорошая архитектура не усложняет, а упрощает. Начинайте просто, масштабируйтесь осознанно, и ваши состояния всегда будут под контролем.

Спасибо за внимание!

Трансформируйтесь от хаоса к гармонии.

Если интересно, подписывайтесь на мой канал, там больше тем, которые не входят в формат Хабра.