BaseViewModel

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

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

К какому выводу пришел автор видео? Давайте просто переименуем BaseViewModel в MviViewModel! Тьфу, блять! У меня она так всегда и называлась.

В общем простенькая структура со скрина остается. Если где-то придумали лучше – с радостью бы подсмотрел. Я стал мало копаться в чужом коде, насмотренность падает, ощущаю деградацию. Надеюсь безосновательно.

По сути у нас есть Compose и подход Model–View–Intent. Один источник истины в виде единого State. Предсказуемые переходы состояний и понятный контракт между UI и логикой. UI отправляет намерения, ViewModel их обрабатывает, обновляет State и при необходимости отправляет разовые события через отдельный поток эффектов. События можно перенести куда-нибудь, но много ли выиграем? Я пошел дальше – у меня две базовые вьюмодели. Корутинная вторая отвечает за общий хэндлинг ошибок. Тут исходники.

Вижу здесь как минимум три недостатка:
• Подвешивание one-off эффектов. Событие может приходить не в нужный момент из-за паузы UI.
• Гонка асинхронных интентов между собой при росте их количества.
• Нарушение принципа LSP, когда базовая ViewModel параметризована локальным FeatureEvent и нельзя отправить глобальный AppEvent.

Но для приложений на 20 экранов с 3 кнопками на каждом – более чем достаточно и просто в реализации.