#Patterns Всем привет! State или как не плодить кучу условий и сложной бизнес логики Часто бывает такое, что у сущности есть n-ое количество состояний, например Заказ: создан -> оплачен -> отправлен -> доставлен ->(опционально) возвращен и так далее, может быть много ответвленний, много запретов и так далее, если сделать это в лоб, то получим ситуацию, в которой приходится учитывать очень много вводных, что на больших сущностях очень тяжело и именно в этот момент нам на помощь приходит State. С помощью State мы не просто описываем список состояний, а выносим поведение каждого состояния в отдельный объект. То есть логика "что можно делать?" зависит не от строки со статусом, а от конкретного объекта состояния. Любое действие pay(), deliver(), cancel() это вызов метода у текущего состояния. Если переход возможен - состояние меняется, если нет - возвращается ошибка. Когда State Machine будет полезна? 🔤когда есть четкие состояния и правила переходов. 🔤когда важно запретить неправильные сценарии. 🔤когда объект используется в многих частях системы и часто изменяется. 🔤когда разные состояния меняют поведение объекта. 🔤 когда бизнес-логика начинает разрастаться. Реальный кейс использования Представьте заказ в интернет-магазине: 🔤состояния: CREATED, PAID, SHIPPED, DELIVERED, CANCELED 🔤события: pay(), deliver(), cancel() 🔤правила: нельзя deliver() пока не PAID, нельзя pay() после CANCELED При этом: - каждое состояние реализует своё поведение - переходы происходят внутри него - добавить новое состояние = добавить новый класс - изменить правило = изменить конкретное состояние Подробнее почитать можно тут - тык Почитать с рунета тут - тык