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

Введение

VIPER, подобно современным блогерам, собрала вокруг себя достаточно много хайпа. У неё появились как хейтеры, так и люди, свято верующие в идеальность этой архитектуры. Хейтеры VIPER породили множество заблуждений разного характера. Вот некоторые из них:

• В VIPER модуле слишком много классов
• Высокий порог вхождения — неопытные программисты не смогут с ней работать
• На множество проблем нет стандартизованного решения
• Presenter — ненужный компонент, который занимается исключительно посредничеством
• Зачем мне 99% покрытие кода тестами, которое обеспечивает VIPER?

Не могу похвастаться большим числом проектов, написанных мной с использованием VIPER, но всё же они есть. И, исходя из своего опыта, могу сказать, что на все эти заблуждения есть вполне логичные ответы.

О большом количестве классов

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

О пороге вхождения

Теперь про порог вхождения. Он действительно «большой», но только для новичка. Не скрою — я и сам не сразу разобрался как написать VIPER модуль, но и опыта разработки в то время у меня было всего несколько месяцев. А, когда мы в компании первый раз решили использовать VIPER, моим коллегам было достаточно одного code review готового модуля чтобы написать свой. Так что архитектура совсем несложная, сложно заставить себя в ней разобраться.

О стандартах

На первый взгляд кажется, что все в VIPER понятно — View отображает, Interactor предоставляет, Router переходит, а Presenter связывает. Но это только верхушка айсберга. Когда начинаешь писать первый модуль, то часто не можешь понять — где писать определенный код. И многие программисты основываются на чужих решениях, которые могут решать одну проблему по-разному. И программисты начинают говорить про то, что VIPER — это плохо. Мне кажется, что тут дело не в VIPER, а в тех самых примерах, которые смотрят люди. Какова вероятность, что человек хорошо разобрался в архитектуре перед тем как выложить свой код? Столько же сколько и вероятность встретить динозавра на улице — 50%. Поэтому прежде всего надо думать своей головой и тогда всё встанет на свои места. На самом деле в VIPER очень чётко разделены обязанности между компонентами модуля. И, если Вы не знаете куда отнести какую-то вещь, то просто перечитайте ещё раз про VIPER или посмотрите книгу Rambler&Co.

О Presenter'е

Бытует мнение, что Presenter выполняет роль посредника между View и Interactor, и что этот компонент лишний в VIPER модуле. Тут я скажу, наверно, очевидные вещи, но всё же. Во-первых, Presenter хранит состояние всего модуля. Во-вторых, Presenter выступает в качестве Input и Output модуля. В-третьих, он не просто передает команды от View к Interactor и т.д., а принимает решения — в каком случае что именно надо сделать, а это уже не совсем посредничество.

О тестировании

И последнее — зачем же нам 99% покрытие кода тестами, которое обеспечивает VIPER? На первый взгляд ответ на вопрос лежит на поверхности — затем, чтобы быть уверенным в корректной работе приложения. Но тут дело, скорее всего, не в цифре, а в самом факте того, что VIPER это позволяет. И позволяет сделать достаточно легко в отличии от некоторых других архитектур. И при разработке любых по сложности проектов это является огромным плюсом.

Заключение

Да, у VIPER есть свои недостатки (нет ничего идеального), но не стоит ей пренебрегать. Но и не стоит использовать её во всех проектах подряд. Всё-таки архитектура приложения выбирается исходя из множества различных факторов и требований, а не только из-за фанатизма. И, прежде чем говорить что она плохая или хорошая, стоит написать на ней 2-3 приложения, чтобы всё как следует взвесить.

Надеюсь, я не превысил количество слова VIPER на квадратный сантиметр.
Спасибо за прочтение!