Why VIPER is a good choice for your next application.
When I read an article in which the author spoke about the fact 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.
VIPER, like modern bloggers, has gathered quite a lot of HYIP around itself. She had both haters and people who are holy believers in the ideality of this architecture. Haters VIPER gave rise to many misconceptions of a different nature. Here are some of them:
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 errors.
Let's start with the fact that in architecture there are a lot of classes and protocols for a reason. This is necessary to ensure weak connectivity and high mesh, which together make the code understandable, easily supported, reusable, and resistant to external changes. This makes it easier to work on a project, and it doesn’t matter whether it’s a team development or not. VIPER, thanks to the observance of these principles, makes it easy to change parts of the module, thereby ensuring a quick response to changes in design or requirements.
')
Now, about the threshold of entry. He is really "big", but only for a beginner. I will not hide - I didn’t immediately figure out how to write the VIPER module, but I had only a few months of development experience at that time. And when we first decided to use VIPER at the company, my colleagues had only one code review of the finished module to write their own. So the architecture is quite simple, it is difficult to force yourself to understand it.
At first glance, it seems that everything in VIPER is 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 certain code. And many programmers are based on other people's solutions that can solve one problem in different ways. And programmers start talking about the fact that VIPER is bad. It seems to me that this is not a matter of VIPER, but of the very examples that people watch. What is the probability that a person has a good understanding of the architecture before putting 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 head and then everything will fall into place. In fact, VIPER is very clearly divided responsibilities between the components of the module. And, if you do not know where to put some thing, then just re-read about VIPER or look at the book Rambler & Co.
There is an opinion that Presenter plays the role of 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, the Presenter stores the state of the entire module. Secondly, the Presenter acts as an Input and Output module. Thirdly, he does not just transmit commands from View to Interactor, etc., but makes decisions on which cases need to be done, and this is not entirely mediation.
And finally, why do we need 99% coverage of the code with tests that VIPER provides? At first glance, the answer to the question lies on the surface - then, to be sure of the correct operation of the application. But the point is most likely not in the figure, but in the very fact that VIPER allows it. And allows you to do quite easily in contrast to some other architectures. And when developing projects of any complexity, this is a huge plus.
Yes, VIPER has its drawbacks (there is nothing perfect), but do not neglect it. But you should not use it in all projects in a row. Still, the architecture of the application is selected based on many different factors and requirements, and not just because of fanaticism. And before saying that it is bad or good, you should write 2-3 applications on it to weigh everything properly.
I hope I did not exceed the number of words VIPER per square centimeter.
Thanks for reading!
Introduction
VIPER, like modern bloggers, has gathered quite a lot of HYIP around itself. She had both haters and people who are holy believers in the ideality of this architecture. Haters VIPER gave rise to many misconceptions of a different nature. Here are some of them:
- VIPER module has too many classes
- High threshold of entry - inexperienced programmers will not be able to work with it
- There are no standardized solutions for many problems.
- Presenter - an unnecessary component that deals exclusively with mediation
- Why do I need 99% code coverage with tests that VIPER provides?
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 errors.
About a large number of classes
Let's start with the fact that in architecture there are a lot of classes and protocols for a reason. This is necessary to ensure weak connectivity and high mesh, which together make the code understandable, easily supported, reusable, and resistant to external changes. This makes it easier to work on a project, and it doesn’t matter whether it’s a team development or not. VIPER, thanks to the observance of these principles, makes it easy to change parts of the module, thereby ensuring a quick response to changes in design or requirements.
')
On the threshold of entry
Now, about the threshold of entry. He is really "big", but only for a beginner. I will not hide - I didn’t immediately figure out how to write the VIPER module, but I had only a few months of development experience at that time. And when we first decided to use VIPER at the company, my colleagues had only one code review of the finished module to write their own. So the architecture is quite simple, it is difficult to force yourself to understand it.
About standards
At first glance, it seems that everything in VIPER is 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 certain code. And many programmers are based on other people's solutions that can solve one problem in different ways. And programmers start talking about the fact that VIPER is bad. It seems to me that this is not a matter of VIPER, but of the very examples that people watch. What is the probability that a person has a good understanding of the architecture before putting 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 head and then everything will fall into place. In fact, VIPER is very clearly divided responsibilities between the components of the module. And, if you do not know where to put some thing, then just re-read about VIPER or look at the book Rambler & Co.
About Presenter
There is an opinion that Presenter plays the role of 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, the Presenter stores the state of the entire module. Secondly, the Presenter acts as an Input and Output module. Thirdly, he does not just transmit commands from View to Interactor, etc., but makes decisions on which cases need to be done, and this is not entirely mediation.
About Testing
And finally, why do we need 99% coverage of the code with tests that VIPER provides? At first glance, the answer to the question lies on the surface - then, to be sure of the correct operation of the application. But the point is most likely not in the figure, but in the very fact that VIPER allows it. And allows you to do quite easily in contrast to 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 do not neglect it. But you should not use it in all projects in a row. Still, the architecture of the application is selected based on many different factors and requirements, and not just because of fanaticism. And before saying that it is bad or good, you should write 2-3 applications on it to weigh everything properly.
I hope I did not exceed the number of words VIPER per square centimeter.
Thanks for reading!
Source: https://habr.com/ru/post/321590/
All Articles