Как я описал ранее, если раскидывать очень много флагов по системе, мы можем упереться в сложность расширения схемы и в какой то момент может получится дублирование кода. Например один и тот же флаг может одинаково обрабатываться в 2х различный вариантах. Что касается экранов, это вытекающее из флагов, потому что даже запуск “первого” экрана нашей функциональности это выбор из 4х при различных условиях, и в каждый экран мы можем вернуться со своими данными. Плюсом накладывается условие, из какого конкретно экрана мы пришли.
Что касается switch case, на мой взгляд это не совсем сравнимые вещи, потому что основное условие стейт машины, помимо того, что мы можем в один момент перейти только в одно состояние, так это еще и знание, в каком состоянии конкретно мы сейчас находимся и куда мы имеем право идти.
switch безусловно может решить проблему перехода по состояниям, но вот накладывать ограничения на переходы, это уже не его зона ответственности на мой взгляд.
Все графические схемы были сделаны скорее для удобства и наглядности. Чтобы любой из команды мог взглянув на нее, понять, что и куда может вести. Безусловно, можно было описывать честную state диаграмму. Но на момнет реализации, мы были сфокусированы прежде всего на функциональности. Думаю стоит этот момент учесть
Что касается switch case, на мой взгляд это не совсем сравнимые вещи, потому что основное условие стейт машины, помимо того, что мы можем в один момент перейти только в одно состояние, так это еще и знание, в каком состоянии конкретно мы сейчас находимся и куда мы имеем право идти.
switch безусловно может решить проблему перехода по состояниям, но вот накладывать ограничения на переходы, это уже не его зона ответственности на мой взгляд.