Когда я прочитал статью, в которой автор рассказал про то, что архитектура 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 на квадратный сантиметр.
Спасибо за прочтение!
Поделиться с друзьями
-->

Комментарии (11)


  1. s_suhanov
    13.02.2017 14:14

    Вот знаете, не могу с вами не согласиться. По сути, просто нужно понимать где VIPER будет хорош, а где нет. Поэтому, в принципе, можно считать что оба поста: за VIPER и против — дополняют друг друга. :)


    1. NoFearJoe
      13.02.2017 16:37

      Я просто хотел восстановить равновесие)


  1. serg_p
    13.02.2017 14:48
    +1

    Размышления, описание- проблем есть. Ни примеров — ни выводов?????


  1. tapoton
    13.02.2017 16:38

    Не могу не согласиться с автором.

    Только чувствую, как сейчас понабегут с криками, что автор адепт секты.

    Из данной статьи в очередной раз можно вынести, что не нужно читать подобные статьи на тему «оно плохое». Если интересно, разберись и для себя реши.


  1. RomanVolkov
    13.02.2017 16:38
    +2

    Мне иногда кажется, что VIPER придумали ради холиваров. Я пока не видел другого такого архитектурного паттерна, про который везде спорят. Везде.


  1. syouth
    13.02.2017 17:41

    «Во-первых, Presenter хранит состояние всего модуля»
    А для чего тогда модель(ну или энтити, как она называется в вайпер)?


    1. NoFearJoe
      13.02.2017 17:43
      +1

      Модель хранит данные. Состояние, если говорить просто, определяет что можно сделать с этими данными в текущий момент


      1. syouth
        14.02.2017 14:10

        Ну ок.
        А при сериализации(ну например нужно сделать сейв) вы это состояние из пресентера куда сбрасываете?
        Просто то, что вы описали — это не состояние а скорее логика смены состояний. Само состояние как раз таки хранится(ну по крайней мере должно) в модели.


  1. IbrahimKZ
    14.02.2017 11:13

    Вы используете классический VIPER или немного модифицированную версию от Рамблера? Или между ними нет существенной разницы?


    1. NoFearJoe
      14.02.2017 14:20

      Я использую версию от Рамблер, но с незначительными изменениями, которые мы решили сделать в компании.
      Между этими версиями есть разница — о ней писали в Рамблере. В основном, в компаниях видоизменяют архитектуру исходя из собственных взглядов и требований(например, в uber используют Riblets). В этом нет ничего плохого, так как основная задача — следовать принципам чистой архитектуры.


  1. ned19
    14.02.2017 14:14
    +1

    Сам когда-то думал что VIPER это громоздко, ненужно и вообще просто «модно». После применения этой архитектуры в нескольких проектах я поменял своё мнение :)