SOLID Principles Explained
So even Your Grandma Would Get It
We decided to create a blog about the SOLID Principles and began researching. There are hundreds of articles available, but the majority of them use highly technical language, giving the impression that they are explaining something extremely advanced. We believe that technology concepts can be explained in very simple terms using real-world, everyday examples. Here's our take on explaining SOLID principles in a way that even your grandmother can understand.
Single Responsibility Principle
Example
Imagine you're cooking Easter dinner. You have sous-chefs lined up, each with a specific task—one chops vegetables, another preps sauces, and another bakes desserts. You assign everyone a single job, and off you go to cook together.
Implication
A class with many responsibilities increases the possibility of bugs because one may make changes in one responsibility and unknowingly affect other responsibilities.
Goal
This principle is designed to isolate behaviors from each other so that if a bug is introduced due to a change, it won't affect other unrelated behaviours.
Open/Closed Principle
Example
Think about a bare refrigerator, and say you want to store a few specific things. You do not drill new holes or destroy the structure of the fridge. You just add accessories, like a fruit basket, an egg tray or a bottle holder!
Explanation
If you want to enhance a class/module/function, it is most effective if new functions are added, not changing old functions.
Goal
This principle states that the extension of a class's behavior must be achieved without altering the existing behavior so as not to generate bugs in the class where it is already used.
Liskov Substitution Principle
Example
If you know how to work one espresso machine, you should be able to use any espresso machine, advanced features aside, because they all operate the same way.
Explanation
If you make a child class from a parent class, then the child should be able to do everything the parent can do. This would be consistent and avoid bugs where the child class cannot do what the parent can.
Goal
This principle ensures that there is enough consistency in using a parent class and its child class interchangeably without any errors.
Interface Segregation Principle
Example
If you need to grate some carrots, it is better to use a simple grater than some multi-tool kitchen robot. Since the grater is created especially for this it works in a more straightforward way.
Explanation
When a class performs actions that serve no purpose within its role, it becomes wasteful and could potentially produce all sorts of unexpected bugs. The class should perform only those actions that are necessary to perform the role. Actions which are not useful for a role should be removed or moved to another class if they can be useful for its specific role.
Goal
This principle aims to split actions into smaller, more focused sets so that a class executes only the actions it requires.
Dependency Inversion Principle
Example
When following a recipe, high-level tasks like preparing a meal shouldn’t depend directly on specific tools like a knife or pan. Instead, they depend on general instructions that any suitable tool can fulfill.
Explanation
Dependency inversion means relying on interfaces or abstract functions and classes rather than on concrete implementations. High-level classes should not depend on low-level classes but on abstractions.
Goal
This principle intends to reduce the dependency of high-level classes on low-level classes by bringing an interface in between so that details are dependent on abstractions, not vice versa.
By following these guidelines, you can develop software that is more robust, flexible, and maintainable. These five principles may appear to be difficult to grasp, but their goal is to assist you in writing code that is simple to adjust, extend, and test with as few issues as possible.
