Опиши архитектуру VIPER

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

Не столько знание пяти букв, сколько понимание, зачем такое дробление нужно и какой ценой достаётся. Обычно следом спрашивают, стали бы вы брать VIPER в текущий проект.

Как отвечать

VIPER это разделение модуля экрана на пять ролей:

• View: отображает то, что ему сказали, и передаёт действия пользователя дальше. Логики не содержит, обычно это UIViewController;
• Interactor: бизнес-логика и работа с данными, сеть, база, кеш. Про интерфейс не знает ничего;
• Presenter: посредник. Принимает события от View, просит данные у Interactor, готовит их к показу и отдаёт обратно;
• Entity: модели данных, простые структуры без поведения;
• Router (Wireframe): навигация и сборка модуля, решает, какой экран открыть следующим.

Связи между слоями обычно объявляются протоколами, поэтому каждый слой подменяется заглушкой в тестах, и Presenter тестируется без запуска интерфейса.

Ради чего это делается: у толстых контроллеров вся логика оказывается в одном файле на полторы тысячи строк, а VIPER разносит её по ролям с явными границами. Плата тоже понятная: на простой экран приходится пять файлов и набор протоколов, поэтому в маленьком приложении накладные расходы перевешивают пользу.

Хорошо, если добавите сравнение: MVP отличается отсутствием отдельного Router и Interactor, MVVM строится вокруг привязки данных, а Clean Swift (VIP) убирает двусторонние связи, замыкая поток в цикл.

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

Кладут бизнес-логику в Presenter. Тогда Interactor вырождается в обёртку над сетью, а смысл разделения теряется.

Дают View прямой доступ к данным или к навигации, минуя Presenter и Router.

Говорят «VIPER лучше MVVM» без оговорок. Ответ сильнее, когда вы называете условие: большая команда, длинный жизненный цикл, много похожих экранов и требование к тестам. На маленьком проекте это лишняя сложность.