Is your code STUPID or SOLID?
 |
| Source: https://blogs.msdn.microsoft.com/cdndevs/2009/07/15/the-solid-principles-explained-with-motivational-posters/ |
These are just acronyms that describe certain errors and principles in writing a code. From the name, it can be understood that the first approach is bad and should be avoided. At the same time, the second one is correct and experienced programmers stick to it. But what are they?
I propose to begin with determining the acronyms.
Firstly, we have STUPID:
• S - Singleton
• T - Tight Coupling
• U - Untestability
• P - Premature Optimization
• I - Indescriptive Naming
• D - Duplication
So here is SOLID:
• S - Single Responsibility
• O - Open / Closed
• L - Liskov Substitution
• I - Interface Segregation
• D - Dependency Inversion
You will often have questions about the SOLID during the recruitment. Well, if you are asked what a STUPID or SOLID is, then you can already answer it or at least determine it. But it is worth delving into each point of each approach in order to understand what it is and why it is worth being a SOLID developer, not a STUPID one.
Let's go in order, namely, let's start with the STUPID points.
Singleton
A singleton is a design pattern that guarantees that there is only one single instance of a class in an entire application. Of course, in certain cases, it can be convenient, but singletons often make testing difficult, and with illiterate use, they can even lead to memory leaks.
Tight coupling
Strong dependencies are evil that we should avoid. Initializing the dependencies in the constructor or immediately in the variable leads to closing the possibility of easy substitution of objects. A good example is the data source. For example, usually the application uses data from the network, but in tests, we want to simulate this source locally. The solution to this problem is the Dependency Inversion described in one of the SOLID principles.
More info: https://en.wikipedia.org/wiki/Loose_coupling
Untestability
Everything is simple – a badly written code is always difficult to test. This is partly due to improperly created dependencies, as it was described in the point above.
Premature Optimization
Premature optimization, as a rule, complicates code readability. Therefore, you should avoid this.
Indescriptive naming
Everything is also clear here - think up readable and understandable names for classes, methods, and variables so that you will not waste your time trying to figure out what it is for.
Duplication
Many programmers forget about code reuse and they duplicate parts of it, sometimes even classes. One should always try to use the already existing methods and, if possible, make genetic classes.
More info : https://en.wikipedia.org/wiki/Duplicate_code
Here we have just understood the bad approach - STUPID. Let's now take a look at the SOLID.
Single Responsibility Principle
 |
| Source: https://blogs.msdn.microsoft.com/cdndevs/2009/07/15/the-solid-principles-explained-with-motivational-posters/ |
This principle suggests that each class should be responsible for one specific functionality only. Thanks to this approach, we have the opportunity to make changes to the class, without fear of the impact of changes on other objects.
Open / Closed Principle
 |
| Source: https://blogs.msdn.microsoft.com/cdndevs/2009/07/15/the-solid-principles-explained-with-motivational-posters/ |
The principle implies that objects should be open for extension, but closed for changes. This means that the developer must organize the class in such a way that in order to adjust it to specific conditions, it will be enough just to extend the class and override some functions.
Liskov Substitution Principle
 |
| Source: https://blogs.msdn.microsoft.com/cdndevs/2009/07/15/the-solid-principles-explained-with-motivational-posters/ |
Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. That’s how this principle is described. This suggests that if the developer decides to extend the class, it will not disrupt the work of the application. For example, if the developer overrides the method from the base class with errors, then only some part of the application will be affected.
Interface Segregation Principle
 |
| Source: https://blogs.msdn.microsoft.com/cdndevs/2009/07/15/the-solid-principles-explained-with-motivational-posters/ |
Have you encountered situations when you need to implement an interface in order to use only a few of its methods? I think yes. In this case, we are forced to implement unnecessary methods. Of course, a pair of empty methods will not greatly affect the readability of the class. But what if the interface has, for example, 10 methods, and we need only 1-2? Actually, this principle describes the solution to this problem. He says that it is necessary to avoid thick interfaces by dividing them into smaller ones.
Dependency Inversion Principle
 |
| Source: https://blogs.msdn.microsoft.com/cdndevs/2009/07/15/the-solid-principles-explained-with-motivational-posters/ |
This principle serves to create loosely coupled entities, what greatly simplifies testing and modifying the already existing code. The description says that top-level modules should not depend on lower-level modules, but they should depend on their abstractions. Abstractions are independent of the details, while the details must depend on the abstractions. This means that we should not create instances of objects inside a class, we must pass them through constructs.
Conclusion
From my personal experience, I can say that using SOLID in a project is good and necessary practice. Yes, at first it may seem that this is unnecessary, especially when a project is small. But when it comes to testing and extending, problems start to appear and the programmer needs to do refactoring of the code, rewriting old code fragments, thereby losing his time. When I first started programming, I neglected these principles, which soon sometimes led to almost impossible code content.
Sources
Questions
• Do you use any of SOLID principles?
• Do you have any of the mistakes mentioned in the STUPID approach?
• What can you suggest we should do to make the code more maintainable?
Comments
Tight Coupling. I don't write many tests because of my job specificity, so I sometimes it takes lots of time when client change his mind, and we have to refactor tons of code to support testing.
We should encourage developers to read more about different design patterns and teach them how to do a proper code review. Writing good code is crucial for the success of the product. Having lots of tests is a handy thing thinking of maintainable. A simple way to check if you write a decent code is to try to go back to projects you wrote +2 months ago an try to add something to them. If it's easy, it means that you have written a decent code.