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.


A photo – nesa – Unsplash

Acronym

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

  • The only responsibility (SRP). One module / class – one task. It seems that we already discussed something like that when we analyzed the “Unix philosophy” together with the principles of KISS.
  • Openness / closedness (OCP). Components are extensible and non-modifiable. Bertrand Meyer is considered its founder (Bertrand meyer) – the author Eiffel
  • Substitutions (LSP). The developer should be able to replace a type with a subtype without breaking the system. The type hierarchy must be modeled carefully to avoid confusion. The principle was proposed by Barbara Liskov (Barbara liskov) – one of the authors Clu
  • Splitting interface (ISP). Specialization to decouple them from software entities, plus to make refactoring easier. This principle was defined by Robert Martin (Robert Martin) Is an internationally recognized development expert.
  • Dependency inversions (DIP). Control components should be abstracted from lower-level modules, and details should not depend on abstractions and higher-level modules. Robert Martin suggested this point too (here is the text of his original publication).

If you follow these principles, you structure your classes and functions so that they execute, you are likely to get reliable, understandable, and easily maintainable code. By the way, here there are some good examples to illustrate how the principles work in practice.

Who brought SOLID

As you may have already guessed, it was precisely Uncle Bob… He described them comprehensively in the work “Design Principles and Design Patterns2000, and the acronym SOLID itself was later suggested by engineer Michael Feathers. If interested, Michael has bookwhere he gives advice on how to “revive” the legacy system and not go crazy along the way.


A photo – Oskar Yildiz – Unsplash

SOLID’s mission is to facilitate the development of applications that are easy to maintain and extend over time. But this set of guidelines is often criticized.

What is criticized for

Sometimes these principles called “Too vague”, which complicates their practical use. Programmer and writer Joel Spolsky at one of the issues The StackOverflow Podcast also noted that the SOLID methodology is too utopian and forces developers to spend time on redundant code for the sake of a tick.

He believes that there is no need to try to take into account all possible scenarios in advance 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 opinionthat 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. With this statement agree many who think that focusing on simplicity of code is enough for other developers to support it.


A photo – Kevin Canlas – Unsplash

In the topic thread on Hacker News say and that the choice of architecture, technology stack and management of project dependencies is much more important, and not the fundamental principles on which its writing is built. Here again they point to the excessive complexity of starting with a complex 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 it, 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 development rejection syndrome

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.


What we write about in the corporate blog 1cloud.ru:

Unusual interview invitations – from the HTTP header to the message in the search engine
Why developers are more valuable than money, how to save and increase them
Development team suggests switching to UTF-8


Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *