Даже в относительно простых современных интернет-магазинах (например, в hottea.ru) заказ может иметь 10 и больше различных состояний, и больше нескольких десятков переходов между этими состояниями:

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

С использованием конечных автоматов это просто и логично:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

state_machine :state, :initial => :cart do
    event :check do
      transition [:payment_pending, :cart] => :check
    end

    event :send_order do
      transition :check => :sent_and_paid, if: :fully_paid_with_bonus?
      transition :check => :payment_pending, if: :is_payable_online?
      transition :check => :sent
    end

    event :confirm do
      transition :sent => :confirmed
      transition :sent_and_paid => :confirmed_and_paid
    end
  end

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

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

(кликните на картинку, чтобы посмотреть в полном размере)