3/180: SOLID Design Principles
So its a day 3 of Learning out of 180 day challenge. The purpose of this challenge is to make a habit of learning.
Today I am going to talk about
- Single Responsibility Principle
- Open Closed Principle
- Liskov substitution Principle
- Interface segregation Principle
- Dependency Inversion Principle
Single Responsibility Principle
By Single Responsibility principle it refers to a class should have only single responsibility
In the above link you see I have created a journal class which is used to create journals or remove journals, but I am having the journal in the directly, but saving the file doesn’t under the journal class responsibility, so we can create another class to save file to go by the Single Responsibility Principle.
Open Closed Principle
By open close principle it refers to open for extension and closed for modification. When ever we create a class in such way that we don’t have to change the class every time, but to add sum functionality we can extend it.
In the above link, the first class productFilter, let’s say at first we wanted to filter products by color only, after sometime the requirement changed and we wanted to filter products by size also but in this way we are modifying the class again and again and not going by the open closed principle. What we can do to avoid this is we can create 2 different generic interfaces one for specification and opther for filter and can implement this in product filter, so whenever a new requirement will come, we don’t have to do much and just need to pass specification and product
Liskov Subsitution Princple
The idea behind is that you should be able to substitute subclass before base class
LiskovSubsitutionPrinciple.java (github.com)
Interface segregation Principle
This principle is meant to split interfaces to smaller interface so that we don’t have implement function which is not required by that class. So if there are some methods which will be used only in fewer class separate it using different interface
InterfaceSegregationPrinciple.java (github.com)
If you see in the above example, there is a machine interface having print, fax and scan function and we have two class to implement it one is multifunctionprinter and the other is oldprinter, but problem with implementing this interface is that old printer don’t have fax functionality so for us here we have to make changes which are not required. What we can do instead of that is segregate the interfaces and use only where it is required.
Dependency Inversion Principle
People confuse dependency inversion principle with dependency injection but its bit different.
High level modules should not depend on low level modules. Both should depend on abstractions.
Abstractions should not depend on details, details should depend on abstraction
DependencyInversionControl.java (github.com)
PS: This is the course I am doing on udemy which is not yet complete, lot more to come in design patterns.
