О контролеррах, состояниях и пользе событий в асинхронных задачах

---

Описательно/вводная часть предназначается скорее начинающим, вопросительная к более опытным (собственно, а к кому же еще))
Сейчас пишу плеер для потокового видео с прикрученным доп. функционалом. Понятно, что сама по себе задача показать видео не стоит заморочек, но вот доп. функционал… вообщем проект растет и дописать в нем еще есть что.
А написать, и заодно спросить здесь, хотел про организацию сценариев поведения.
С пылу, с жару в основу реализации плеера легли состояния. Состояние «видео играет», «видео на паузе» и пр. К примеру, клик пользователя по кнопке «pause» -> переход в состояние /*капитан очевидность*/ - «видео на паузе». Можно обработать таким вот способом
Ну или для play
Работает гуд, пока, к примеру, работаем с локальными данными, или сервер отвечает быстро.
А вот что происходит, когда он (сервер) задумается что ему с этим делать достаточно долго, так чтобы пользователь успел понажимать play/pause.
Как уже все поняли, получается бардак: сервер думает одно, на экран рисуем совсем другое.
Кому то решение проблемы придет только от фразы «показать видео», кому то не придет) мне мысль об асинхронном мышлении(простите за тавтологию)) в работе с потоковым видео пришла с появлением этого самого бардака.
Благо решение проблемы нашлось сразу: мыслим объектно, делим задачу как минимум на две, получаем следующий мини сценарий.
1. ловим клик пользователя; сообщаем серверу.
2. ловим сообщение сервера о том, что видео поставлено на паузу; отрисовываем замену кнопки.
Ну или кодом
Здесь MainVideoModule - модуль главного видео (есть и другие потоки, к примеру, для функции "картинка в картинке")
Отсюда расширю идею дальше, до моего видения работы контролеров.
На контролер возлагается инициализация всех подконтрольных ему модулей, прописывание связей между ними. В данном примере общение видео модуля с информационной панелькой навигации.
Какие вижу плюсы:
в первую очередь реализована «слабая связанность». Модули живут своей жизнью, добавление нового не привносит ничего нового. К примеру, возможность нажать паузу с того же пульта телевизора (оговорюсь, одна из платформ плеера SmartTV) вносит минимум изменений в проект: добавили модуль отвечающий за пользовательский интерфейс ( UI ), легко пристыковали его в работу.
В код контролера плюс строка
MainVideoModule[UIEvents.SET_PLAY] = Delegate.create(MainVideoModule, MainVideoModule.play);
механизм упрощает не только добавление новых, но и "выстегивание" временно не нужных модулей - достаточно закомментировать одну строку инициализации модуля.

Ну это о плюсах, а вот теперь о минусах и вопросах к опытным))
Как уже говорил, проект растет. Теперь таких вот «плюс строка» в главном контролере набралось около двух сотен. Дабы не запутаться, что подключил, что нет, стал организовывать код сценариями поведения, к примеру, сценарий логина к серверу в упрошенном виде
Step.1. клик по кнопке логин, показываем поля для ввода, блокируем прочие модули
Step.2. отправляем на сервер пару логин/пароль
Step.3. получили ответ, смотрим результат, при косяке повторить
Step.4. делаем выводы, скрываем окно авторизации, открываем скрытые панели
Достаточно короткий сценарий, всего четыре пункта, некоторые по 10 и по 15.

Что смущает сейчас: обилие записей, что увеличивает вероятность ошибки не связать кого либо.
Чего хотелось бы: большей компактности, может быть, реализацию сценариев через монады.
Ну к примеру, записей подобного рода
Вообщем кто сталкивался, прошу указать вектор.
Чуть не забыл, отдельное БОЛЬШОЕ спасибо iNils за делегат.