SOLID Principles: Explained with really simple real-life examples
In my first job as a Backend Developer I had to learn what SOLID principles are. At first, I couldn’t understand them correctly and I don’t know how to apply them. But with practice, I’ve discovered the huge impact they had on my way to write code and the great improvement my code had since I started using these principles.
In this article, I’m going to explain roughly SOLID Principles and give you some real-life examples so that you can understand them better. However, you’re not going to find an advanced explanation of these principles and you’re not going to find any code examples in this article. This article’s only to learn and understand these principles. But don’t worry, I will explain them in deep in the future.
Are you ready to become a better developer? Let’s start.
What are the SOLID Principles?
Robert C. Martin introduced the SOLID principles in his paper “Design Principles and Design Patterns”. There are design principles (good practices which encourage us to create more flexible, maintainable, and readable software). If we follow these principles, we can write better code.
SOLID is only the initials of:
- Single Responsibility.
- Open/Closed.
- Liskov Substitution.
- Interface Segregation.
- Dependency Inversion.
So, SOLID principles are only design principles (some good practices that we have to follow if we want to write better code) which we should consider if we want to become better programmers. Don’t you understand clearly why you have to learn them?
Why do I have to learn these principles?
As we add lines of code to our project it becomes increasingly complex. In many cases, we have dependency problems or coupling problems that cause production to take too long. And it is because we do have not a good design. This can happen for many reasons, for example, because we don’t follow such good design principles as SOLID principles.
The SOLID principles were developed to combat some problems that appear when we write code. So if we want to avoid some mistakes or we only want to write better code to save money for our business or win a promotion, we should consider following these principles.
Additionally, they will convert our code into a more extensible, readable, understandable, and maintainable code.
SOLID Principles
Now we’re going to discover the definition of these principles and real-life examples to understand and know how to follow correctly the SOLID principles.
Single Responsibility
If you have a coffee maker you expect that it makes your coffee. You don’t expect the coffee maker to heat up your food, don’t you? And if you want to make a better coffee you know that you have to change your coffee maker, and you know perfectly that you have not to change your toast, right? This is the Single Responsibility principle:
A class should only have one responsibility and it should have only a single reason to be changed.
Open-Closed Principle
Imagine that you’re on holiday and you’re in a hotel. The hotel is so luxurious and you have a lot of things to do: dancing, singing, watching films, taking part in activities… But you don’t have a swimming pool. Nevertheless, you want to go swimming because it’s summer, so you ask to build a swimming pool in the hotel. The hotel accepts but it says that the initial building cannot be changed, so they’re going to build the swimming pool a few meters from the hotel. With this, the hotel now is better and its initial building has not been modified.
And it’s because the Open-Closed principle says:
Software entities (classes, modules, functions, etc) should be open for extension, not for modification.
Liskov Substitution
Okay! You don’t like the previous hotel so you decide that it’s time to finish your holidays. To return to your city you’re going to use your wonderful car with wings (a normal car but cooler because it has wings as decoration). But when you try to start it, you realize that it doesn’t work. So you have no choice and you have to return (sad, obviously) to your city using your normal car (a normal car without wings). You could return to your home using either of the two cars without affecting the objective.
It occurs because Liskov Substitution means that…
A sub-class must be substitutable for its super-class
Interface Segregation
Now imagine that you love building things. You lived your childhood using Lego and dreaming about being an engineer. Nowadays you’re old and you have bought a do-it-yourself winter car. Inside the instruction manual on how to build the car, you find all the features it has and how to implement each of them. You find things like starting the engine, warming up the seats, installation of belts, etc. But you don’t find a feature to refresh the car because it’s a feature of the summer car, and you bought the winter car, so the designers had thought that you’re not going to use it.
They thought it because they knew Interface Segregation Principle:
Larger interfaces should be split into smaller interfaces. Clients should not be forced to implement a function they do no need.
Dependency Inversion
You go to the library and you ask for a specified book. They tell you that they have to request it from the big library. You trust and in two days you have your book. In this example, you want a book (your class), and you trust that the big library has it (something abstract).
For me, this is the most difficult principle to understand and it says that:
Our classes should depend upon interfaces or abstract classes instead of concrete classes and functions. Dependency should be on abstractions, not concretions.
The real definition is a bit more complex but I think the two top lines are sufficient to understand.
Final thoughts
We’ve seen the SOLID principles in an easy and summarized way to understand them correctly using real-life examples. I think every software developer must be aware of these principles if they want to write quality code. It’s right that they’ve conceived to be applied only in object-oriented programming but I think that some of the teachings can be used in other types of programming.
If you’ve not understood totally them don’t worry, they can be really challenging at the start but with practice and constancy, you will dominate them. You’re going to internalize them when you can see the great impact they have on your code.
Do you know about these principles before? Are you using them in your job or in your project?
Conclusions 👋
Thank you! Thank you so much for reading the article. I’d love to know your opinion about it, so don’t dude write it in the comments, I’ll read you.
In turn, if this article has helped you remember that you can give it a clap and share it with your comrades. And don’t forget to follow me if you don’t want to miss any of my articles.
About author🤓
My two passions are technology and communication, so I take every opportunity I can get to talk or write about technology.
Want to connect? 📲
📹 Youtube
¡Thanks! ❣️
