Why VIPER is a good choice for your next app

    When I read an article in which the author said that the VIPER architecture is full of problems, it caused me some negative emotions, after which I immediately decided to write an article in support of architecture.

    Introduction


    VIPER, like modern bloggers, has gathered quite a lot of hype around itself. She appeared both haters and people who sacredly believe in the ideality of this architecture. VIPER haters have generated many misconceptions of a different nature. Here is some of them:

    • There are too many classes in the VIPER module
    • High entry threshold - inexperienced programmers will not be able to work with it
    • There are no standardized solutions to many problems.
    • Presenter - an unnecessary component that deals exclusively with mediation
    • Why do I need 99% test coverage provided by VIPER?

    I can not boast of a large number of projects written by me using VIPER, but still they are. And, based on my experience, I can say that there are quite logical answers to all these misconceptions.

    About a large number of classes


    To begin with, there are many classes and protocols in architecture for a reason. This is necessary to ensure poor connectivity and high engagement, which together make the code understandable, easily maintained, reusable and resistant to external changes. This facilitates the work on the project, and it doesn’t matter whether it is team development or not. VIPER, due to the observance of these principles, makes it easy to change parts of the module, thereby providing a quick response to changes in design or requirements.

    About entry threshold


    Now about the entry threshold. He is really “big”, but only for a beginner. I will not hide - I myself did not immediately figure out how to write a VIPER module, but at that time I had only a few months of development experience. And when we first decided to use VIPER in the company, my colleagues needed only one code review of the finished module to write their own. So the architecture is completely uncomplicated, it is difficult to force yourself to understand it.

    About Standards


    At first glance, everything in VIPER seems to be clear - View displays, Interactor provides, Router switches, and Presenter connects. But this is only the tip of the iceberg. When you start writing the first module, you often cannot understand where to write specific code. And many programmers are based on other people's solutions that can solve one problem in different ways. And programmers are starting to say that VIPER is bad. It seems to me that the point here is not VIPER, but the very examples that people watch. What is the likelihood that a person has a good understanding of architecture before laying out his code? As much as the probability of meeting a dinosaur on the street is 50%. Therefore, first of all, you need to think with your own head and then everything will fall into place. In fact, in VIPER, the responsibilities between the components of the module are very clearly divided. AND,Rambler & Co book .

    About Presenter


    It is believed that Presenter acts as an intermediary between View and Interactor, and that this component is superfluous in the VIPER module. Here I will say, probably, obvious things, but still. First, Presenter stores the state of the entire module. Secondly, Presenter acts as an Input and Output module. Thirdly, he does not just transfer commands from View to Interactor, etc., but makes decisions - in which case what exactly needs to be done, and this is not quite a mediation.

    About testing


    And finally, why do we need 99% test coverage provided by VIPER? At first glance, the answer to the question lies on the surface - then, to be sure that the application works correctly. But here the matter, most likely, is not in the figure, but in the very fact that VIPER allows it. And it makes it easy enough, unlike some other architectures. And when developing projects of any complexity, this is a huge plus.

    Conclusion


    Yes, VIPER has its drawbacks (there is nothing perfect), but you should not neglect it. But you should not use it in all projects in a row. Still, the application architecture is selected based on many different factors and requirements, and not just because of fanaticism. And, before saying that it is good or bad, it’s worth writing 2-3 applications on it to weigh everything properly.

    I hope I did not exceed the word VIPER per square centimeter.
    Thanks for reading!

    Also popular now: