Традиционная реализация паттерна State через классы и наследование часто превращается в кошмар: куча мелких классов, дублирование методов и разбросанная логика переходов. В Python есть более элегантный способ.
В чем проблема классики?
В обычном ООП-подходе каждое состояние — это отдельный класс. Это приводит к тому, что вы пишете много одинаковых методов
raise RuntimeError, если действие недоступно в текущем состоянии. В итоге сложно увидеть всю картину переходов целиком.Pythonic-подход: Дженерики и Декораторы
Вместо иерархии классов можно создать универсальный движок State Machine, который работает как явная таблица соответствий:
(Текущее состояние + Событие) -> (Следующее состояние + Действие).Основные фишки такого дизайна:
1️⃣ Генерики (`Generic`): Движок типизируется через состояния, события и контекст (например, данные о платеже).
2️⃣ Декораторы
@transition: Позволяют описывать логику переходов прямо над функциями действий. Это превращает ваш код в читаемую спецификацию: сразу видно, какие события переводят систему из одного статуса в другой.3️⃣ Принцип открытости/закрытости: Чтобы добавить новый переход, вам не нужно менять существующие классы — достаточно написать новую функцию с декоратором.
4️⃣ Гибкость: Одно действие (например, «ошибка») можно легко привязать сразу к нескольким начальным состояниям через итерируемые объекты в декораторе.
Этот подход идеален для систем с четкими потоками данных: платежи, обработка заказов, логистика или парсеры. Классические классы стоит оставить только в случаях, когда каждое состояние имеет крайне сложную внутреннюю логику и специфичные только для него данные.
📍 Навигация: Вакансии • Задачи • Собесы
Библиотека питониста
#буст