Какие паттерны проектирования использовали: MVVM, VIPER, MVP, MVC

Что проверяют

Различаете ли вы схемы по тому, кто о ком знает, и понимаете ли, что цена у них разная.

Как отвечать

Все четыре решают одну задачу: отделить логику от отображения. Отличаются связью между частями.

• MVC в варианте платформы: контроллер владеет представлением и знает модель. На Android это активность, которая делает всё сразу, отсюда классические файлы на тысячу строк и трудность тестирования;
• MVP: презентер общается с представлением через интерфейс и вызывает его методы явно (view.showLoading()). Представление пассивно. Тестируется хорошо, но интерфейсов много и они разрастаются;
• MVVM: ViewModel держит состояние и ничего не знает о представлении, связь через подписку на данные. В Android это ViewModel плюс StateFlow или LiveData. Ключевое отличие от MVP: ViewModel не вызывает представление, а публикует состояние;
• VIPER: разделение на пять ролей с отдельным маршрутизатором для навигации. В Android встречается редко, чаще берут MVI, где состояние экрана одно неизменяемое, а изменения приходят намерениями. Оба дают строгость ценой большого числа файлов.

> «Работал с MVP на старом проекте и с MVVM на текущем: ViewModel, состояние через StateFlow, Compose подписывается. На сложном экране с большим числом переходов состояния перешли на MVI, потому что уследить за десятком независимых полей стало невозможно».

Где спотыкаются

Называют схему, но не могут сказать, кто в ней о ком знает.

Держат в ViewModel ссылку на активность и возвращают ту же связанность.

Считают VIPER и MVI универсально лучшими, не упоминая цену.

Путают MVVM и MVP: разница именно в способе связи, а не в названиях.