Вопрос проверяет понимание архитектурных проблем UIKit-приложений и причин появления Massive View Controller.
При разрастании MVC-контроллер начинает совмещать слишком много обязанностей. Код становится трудно читать и тестировать. Логика тесно связывается с UI. Любые изменения приводят к регрессиям. Такой контроллер сложно переиспользовать и поддерживать.
Massive View Controller — одна из самых распространенных проблем UIKit-приложений.
MVC формально разделяет ответственность, но на практике контроллер часто становится «центром всего».
Типичные причины:
Отсутствие отдельного слоя бизнес-логики.
Прямая работа с сетью и хранилищем из контроллера.
Навигация, форматирование данных и UI-логика в одном месте.
Перед детализацией важно понять: проблема не в размере файла, а в концентрации ответственности.
Контроллер содержит:
жизненный цикл;
обработку событий;
сетевые запросы;
парсинг;
навигацию.
Найти нужную логику становится сложно.
Контроллер зависит от UIKit.
Трудно изолировать бизнес-логику.
Юнит-тесты либо отсутствуют, либо хрупкие.
Изменение:
API,
модели,
навигации
часто требует правок в одном и том же контроллере.
Логика tightly coupled с UI и жизненным циклом, поэтому ее нельзя использовать повторно.
Вынос логики в ViewModel или Presenter.
Использование сервисов.
Введение координаторов для навигации.
Применение протоколов и DI.
Massive View Controller — сигнал, что архитектура требует пересмотра. Чем раньше начать декомпозицию, тем дешевле и безопаснее развитие проекта.