Background: understanding the principles of SOLID

We will tell you who invented them and what they are. Let's also talk about the criticism of this approach - about why some developers refuse to follow SOLID methodologies.





Photo - nesa - Unsplash



Acronym



SOLID - denotes the first five principles of object-oriented programming:





If you follow this and structure your classes and functions so that the SOLID principles are true, you are likely to get robust, understandable, and easily maintainable code. By the way, there are examples here to illustrate how each principle works.



Who brought SOLID



As you might have guessed, it was Uncle Bob who was responsible for the bulk of the principles . He described them comprehensively in his 2000 Design Principles and Design Patterns , and the acronym SOLID was later suggested by engineer Michael Feathers. If you're interested, Michael has a book where he gives advice on how to "revive" the legacy system and not go crazy along the way.





Photo - Oskar Yildiz - Unsplash



SOLID's mission is to help develop applications that are easy to maintain and expand over time. But this set of guidelines is often criticized.



What is criticized for



These principles are sometimes called "too vague", which makes them difficult to use in practice. Programmer and writer Joel Spolsky also noted in one of The StackOverflow Podcast that the SOLID methodology is too utopian and forces developers to spend time on redundant code, in fact, for the sake of a tick.



He believes that there is no need to try in advance to take into account all possible scenarios and simply program, gradually correcting shortcomings, and not rely on an imaginary "security system". Spolsky does not negate the importance of the principles, but calls them excessive.



There is an opinionthat the SOLID code is weakly coherent and easy to test, but very difficult to understand (criticism uses the word "unintelligible"). The programmer has to write a lot of detailed interfaces and small classes that are more distracting and confusing than helping to set up a system. This statement is shared by many who believe that focusing on simplicity of code is enough for other developers to support it.





Photo - Kevin Canlas - Unsplash



Hacker News Topics Speakand that the choice of architecture, technology stack and project dependency management is much more important, and not the fundamental principles on which its writing is built. Here again they point to the unnecessary complexity of starting with an integrated system design, pointing to the YAGNI principle or " You aren't gonna need it ". To some extent, this is another remix of the classic KISS approach .



We have to admit that there are many statements in defense of SOLID. So, one of the residents of HN says that following these principles will help to quickly replace the conditional library if something goes wrong at the abstraction level. It will be enough to make sure that the tests are running for the new implementation, and that's all, the maximum is to additionally check the dependencies for the old version of the class and, as necessary, use the modified one so that the tests pass successfully. Then there will be no "unnecessary complexity" in the code, and those who will deal with it later will not face the so-called syndrome of rejection of someone else's development .



It is important to remember that the SOLID principles are guidelines only, not strict rules. And there will always be cases when it is better to stick to them and when to retreat.






1cloud.ru:



โ€” HTTP-

,

UTF-8






:









All Articles