The 5 Solid Principles Explained
AutoToday I’d like to talk about SOLID, the first five principles of object-oriented programming that we find essential to building working software. In case he didn’t know, in computer programming, Michael Feathers introduced the SOLID principles acronym for five principles that were defined by Robert C. Martin in the early 2000s.
As you know, to get software to work, we need to have low coupling, high cohesion, and strong encapsulation, which is something that the SOLID principles help us achieve. The idea is that by applying those principles together, you can write better quality code that is robust. The created system becomes easy to maintain, reuse and extend over time. Basically, SOLID principles help software developers achieve scalability and prevent their code from breaking every time it faces change.
Ok, let’s start with the basics, SOLID stands for:
S – Single Responsibility Principle
O – Open-closed principle
L-Liskov substitution principle
I – Interface segregation principle
D – Dependency inversion principle
Let’s look at each principle individually to understand why SOLID can help developers build quality software.
The SOLID principles
1. Single responsibility principle
“There should never be more than one reason for a class to change.”
As you can see, this principle states that an object/class should only have one responsibility and that it should be completely encapsulated by the class. Here, when we talk about a responsibility, we mean a reason to change. This principle will lead to more class cohesion and less coupling between dependency classes, better readability, and less complex code.
It is much more difficult to understand and edit a class when it has multiple responsibilities. So if we have more than one reason to change, the functionality will be split into two classes, each handling its own responsibility.
We care about separating the functionalities because each responsibility is a change access. When a class has more than a single responsibility, those responsibilities are coupled, and this coupling can lead to a fragile code base that is difficult to refactor when requirements arise.
2. Open-closed principle
“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”
Here the idea is that an entity allows its behavior to be extended but never modifying its source code. Any class (or whatever you write) should be written in such a way that it can be used as-is. It can be extended if necessary, but it can never be changed. You can consider this when you are writing your classes. Use the class in any way you need, but modifying its behavior is achieved by adding new code, never modifying old code. The same principle can be applied for modules, packages, libraries.
By applying the open-closed principle, you will achieve loose coupling, improve readability, and ultimately reduce the risk of breaking existing functionality.
3. Liskov Substitution Principle
“subtypes must be substitutable for their base types”
As its name implies, the Likov substitution principle was defined by Barbara Liskov. The idea here is that objects should be replaceable by instances of their subtypes, and that without affecting how your system works from the client’s point of view. Basically, instead of using the actual implementation, you should always be able to use a base class and get the result you were expecting. Often when we want to render an object, we model our classes based on its properties and should focus more on behaviors instead.
This principle basically confirms that our abstractions are correct and helps us get code that is easily reusable and class hierarchies that are very easy to understand.
What many say is that the Liskov Substitution Principle has a very strong relationship with the previous principle, the open-closed principle. Robert C. Martin even says that “an LSP violation is a latent OCP violation.”
4. Interface segregation principle
“Classes that implement interfaces shouldn’t be forced to implement methods they don’t use.”
Here, it is about how to write interfaces. So what is claimed? Basically, once an interface gets too big/fat, you absolutely need to break it down into smaller interfaces that are more specific. And the interface will be defined by the client that will use it, which means that the client of the interface will only know about the methods that are related to them.
Actually, if you add methods that shouldn’t be there, the classes that implement the interface will have to implement those methods as well. That is why; the client should not be forced to rely on interfaces that it does not use. ISP is meant to keep a system decoupled and therefore easier to refactor, change and implement.
5. Dependency inversion principle
“High-level modules should not depend on low-level modules, but both should depend on the abstraction. The abstraction should not depend on the details, but the details should depend on the abstraction.”
Last but not least of the SOLID principles, this principle is primarily concerned with reducing dependencies between code modules. Basically, the Dependency Inversion Principle will be of great help when it comes to understanding how to properly link your system.
If the detail of your implementation will depend on higher level abstractions, it will help you get a system that fits together correctly. In addition, it will influence the encapsulation and cohesion of that system.
conclusion
When developing any software, there are two concepts that are very important: cohesion (when different parts of a system work together to obtain better results than if each part worked individually) and coupling (can be seen as a degree of dependency on a class, method or any other software entity).
Coupling is often present in a lot of code, and as I mentioned earlier, the optimal situation would be to have low coupling and high cohesion. With this brief introduction to the 5 SOLID principles, you will have understood that they help us when it comes to that.
There are so many principles in software engineering and I would recommend that before you write any code you do your research, read and try to understand the principles. Although it seems like a lot, SOLID becomes part of you and your code by continuously using it and adapting its guidelines.