SOLID principles consist of five principles namely:
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
First, what is principle? According to google, one of the meanings of principle is:
a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning.
So, as how I understood it, these principles are a plan of actions that serves as a foundation for a system.
What exactly are these principles about?
Here we go.
From what I've learned, the only thing that I remember is that a class should only have one job.
If I have to explain to someone who doesn't know anything about programming. I think the best explanation is comparing this definition to a real life object.
I think the best fit for this idea is a faucet. You turn it on and water flows out, you turn it off the water stops flowing, the faucet's only job is to control the flow of water and nothing else. You can't make it work like a sink or a plate or any other things, because it only has one job.
The key meaning for me is open for extension but closed for modification.
A class should be extendable but close for modification. Alright, so it's like a parent and child relationship. You can never modify a parent's attribute but it can always be (at this situation) be inherited by the child.
Before we proceed, who is Liskov first and why is it important this principle should be named after this name.
Liskov is a computer scientist. According to wikipedia
The Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address titled Data abstraction and hierarchy.
Liskov substition is about substitution of related classes, so, if a child class is derived from its parent class, it should have the ability to become a substitute of the parent class.
So like for example, the trackpad and mouse, they bought can be substitutable with each other because they have the same functions needed to move the arrow around the screen.
A class should never be forced to implement an attribute from an interface which the class doesn't need.
Consider it like, when you create an interface for game object movement, the main game object (the player character) has the ability to walk, run, climb and dash, adding these to the object movement interface will violate this principle if this interface will be implemented as well with a patrol type enemy, which doesn't need the other functions other than walk or run.
This allows decoupling... but wait, what is decoupling?
According to google, decoupling means
separate, disengage, or dissociate (something) from something else.
Hmm.. I still find this vague. If anyone can explain this to me like I'm a 12 years old, please do. But I will update this later if ever I get the whole idea.
I read SOLID principle from https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-designhttps://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design