Есть 4 состояния для приложения A. Для просты восприятие сразу прям как по задаче.

Dead, Not Connected, Hovering (аля завис), Normal.

Тем или иным способом приложение B каждые N секунд присваивает A, одно из этих состояний. Вполне нормальная ситуация, если приложение A работает корректно, то череда его состояний будет Normal -> Normal -> Normal -> ...

Между состояние возможны следующие переходы. 

Dead -> во все
Not Connected -> Dead, Normal
Hovering -> во все
Normal -> во все.

При переходе во любое состояние кроме Normal, производится какое то действие. Переход самого в себя не может быть (т.е. Dead -> Dead), на Практике, если A сломан, то на каждой итерации проверки, ему будет присваиваться статус Dead, но только при первом таком переходе (например Normal -> Dead) должно выполнится некое действия соответствующее состянию Dead. В дальнейшем (Dead -> Dead) просто игнорируется.

До появление состояние Hovering, все это было реализовано следующим образом



В принципе не шибко сложно. Появление же нового статус делает все немного мрачнее. А то, что еще нужно учитывать что в него можно перейти не из любого состояния, делает такую последовательность if-else вообще хреного понимаемой. А еще и не нулевая вероятностью появления новых состояний.

В следствии чего возник вопрос, наверно есть какие то устоявшиеся алгоритмы, принципы, подходы к решению подобного рода задач ?

суть, я думаю. уловишь:

Я делал state machine на классах. 

Имеем набор классов с общим абстрактным предком. У у каждого класса есть метод "state" собственно это состояние и обрабатывающий. Метод возвращает ссылку на следующий класс. В результате этот огромный if аккуратно и лекгочитаемо размещен мелкими порциями в разных классах.

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