Understanding the famous SOLID principle

This is just the tiresome part of interviews for most junior developers. I can’t imagine how much PTSD data structures and algorithms, Object-Oriented Programming, and architectural principles have caused people.

Well, if you have heard of OOP, then you’ve probably have heard about the SOLID principles.

But what is SOLID?

SOLID principles are five principles that help and guide software developers to make their code dynamic, easy to adjust, extend and test with little or no problems. In the long run, it enables scalability. SOLID is a five software development principles and guidelines with each of the letters representing a principle. I would try as much as possible to make this as simple and relatable as possible.

Let’s jump right in.

S – Single Responsibility:

Given that Mr. A has 4 jobs daily; he is a chef, a chauffeur, a gardener, a bartender. There is every probability that at the end of the day, he burns out. There is a bigger probability that he might not be effective in doing his duties, hopefully, he doesn’t sleep while driving and cause an accident. Lol. But how about he employs 3 people, each person taking care of each role and he does the last one; isn’t that better?

Well, that’s what Single responsibility helps solve. Given that a Class has many responsibilities (functionality), it increases the possibility of bugs because making changes to one of its responsibilities, could affect the other ones without you knowing. The principle aims to separate behaviors so that if bugs arise as a result of your change, it won’t affect other unrelated behaviors.

Easy right…. Let’s go to ‘O’.

O – Open-Closed

Let’s paint another scenario. You come across Mr. B in the morning, he introduces himself as a Frontend developer. Later that evening you come across him again and this time he says he is a backend developer. Bruh, you just told me this morning that you are a frontend developer?

Won’t it be better if he said by evening: ‘Hey man, alongside frontend development, I also do backend development, in case you got a gig for me’

Well, this explains the concept of open-close. In simple terms: Classes should be open for extension, but closed for modification, meaning that one should be able to extend the behavior of a class without changing the existing behavior of the Class. Changing the present behavior of a Class will affect all the systems using that particular class. Hence, if you want a Class to perform more functions, it's expedient that you add to the already existing functions and not alter them.

SO…. LID..

L – Liskov Substitution

Well, the basic idea behind this principle is inheritance. ‘If I born pikin, my pikin suppose carry my gene and not oyibo man own’. Here, a child Class should be able to process the same requests as the parent Class. When a class Class cannot perform the same actions as its parent Class, this can lead to bugs. The aim of this principle is to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.

Closer and closer… we are coming to the end. Let’s talk about ‘I’

I – Interface Segregation Imagine telling all the students of a mixed class to button up their pinafore (I hope I spelled that right… But you get the drill).

Wait a second, boys don’t wear pinafore, so what’s the plan? (Me too, I don’t know ooo)

Classes should not be forced to depend on methods that they do not require. When such a scenario happens, this might lead to unexpected bugs especially when the classes do not have the ability to perform such actions. So, therefore, a Class should only perform actions that are needed to fulfill its role, every other action ‘e no concern him papa sha’. In summary, a Class should only execute the set of actions it requires.

The last one? OMG... Let’s get this shit

D – Dependency Inversion

So, I really can’t come up with a use case for this. Wait, I think I just did. Let’s try. For most homes that use refrigerators and freezers, you tend to see a stabilizer, right? Why? Well, the stabilizer is there to regulate the voltage that goes into the electronics. So when the voltage coming in is high, it shuts out some, so that only adequate voltage goes through, and when the voltage is too low, you notice that sometimes it switches on delay, which basically breaks up the voltage until it receives a sufficient amount… Wiunn. Back to programming. Lol Well, we are not breaking up ‘Classes’ in this case. What I basically want you guys to understand is that, in Dependency Inversion, the same way that the fridge doesn’t have access to the main source but to an abstraction of the source (stabilizers), it is the same way that the Class should not have access to the database for instance, but an interface that is a direct duplication of the database. The aim of this principle is to reduce the dependency of a high-level Class on the low-level Class by introducing an interface.

So we are doneeeeeeeeeeeeeeeeeeeeeeeee.. hehe…

I have shared with you guys the five SOLID principles in the best possible way that I can make you understand them.

Do well to like comments and share so as to reach to whoever would need them.

Do well also to reach out to me on Twitter and LinkedIn. Ese ooooo

DANKE…. OBRIGADO