SOLID is one of the most popular sets of design principles in object-oriented software development. Even if you didn’t know what SOLID stands for, most probably you have heard the word before.
In this article, we’ll be discussing these principles . We will try to make things as simple as possible to developers to understand and apply them in their daily work.
SOLID is a mnemonic acronym for the following five design principles:
1- Single Responsibility Principle (SRP)
2- Open/Closed Principle (OCP)
3- Liskov Substitution Principle (LSP)
4- Interface Segregation Principle(ISP)
5- Dependency Inversion Principle (DIP)
Single Responsibility Principle
Robert C. Martin describes it as:
A class should have one, and only one, reason to change.
This principle states that a class should only have one responsibility. Furthermore, it should only have one reason to change.
Let’s have a look at this specific class below:
As you can see, the class Task is responsible for :
1- Downloading something from the internet
2- Parsing file
3- Saving data to the database
Is that meeting the Single Responsibility Principle and you will be able to reuse this kind of code in anywhere else ? The answer is NO !!!
This class is with multiple responsibilities , So SRP is all about having classes which do one thing.
Let’s look at this example :
This is actually doing 2 responsibilities connection and data channel
which could be resolved as below:
How does this principle help us to build better software?
Let’s see its benefits:
- Testing : A class with one responsibility will have far fewer test cases
- Lower coupling :Less functionality in a single class will have fewer dependencies
- Organization : Smaller, well-organized classes are easier to search than monolithic ones
Open/Closed Principle
The second most important principle is open closed principle, it says:
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
Initially , let’s suppose we have a client’s requirement to calculate a rectangle’s area. So we did it as below:
Then, our client wanted another features which consists to calculate a circle’s area. We tried this solution :
It’s not the best, what if we have been asked to add a few more shapes( for example triangle) , all the logic would be centralized in this specific piece of code so whenever we add a new object then we should modify the Area method.
The best solution is to allow each shape to define their own logic like this:
So we created an abstract class called Shape (this could also be an interface) and we have overridden the area method inside each subclass (Rectangle and Circle).
The area method would only be responsible for looping around shapes and calling the area method on the specific shape.
By extending the Shape class we can be sure that our existing application won’t be affected.
In the next part, we are going to dive into the other three principles…
Hope you enjoyed this lecture. See you soon ;)
Sharing_knowledge_improves_yours!!
