Robert C. Martin gave five objected oriented design principles, and the acronym “S.O.L.I.D” is used for it. Each letter of this acronym talks about one principle. When we use all the principles of SOLID, it becomes easier for us to develop software that can be managed easily. The popularity of SOLID became apparent because of the following reasons:
- It avoids code smells
- Quickly refactor code
- Can do adaptive or agile software development
Now, we will look into each of the principle.
S: Single Responsibility
One class should have one and only one responsibility
- Write, change and maintain a class for only one purpose. This gives the flexibility to make changes in future without worrying the impacts of changes for another entity.
O: Open-Closed Principle
Software components should be open for extension, closed for modification.
- Classes should be designed in such a way that whenever fellow developers wants to change the flow of control in specific conditions in application, all they need to do is extend the class and override some functions.
L: Liskov’s Substitution Principle
Derived types must be completely substitutable for their base types
- Classes created by other developers by extending your class should be able to fit in application without failure
- If a developer poorly extended some part of your class and injected into framework or application, then it should not break the application or throw fatal exceptions.
I: Interface Segregation Principle
Clients should not be forced to implement unnecessary methods which they will not use.
Consider an example, an interface Reportable has two methods generateExcel() and generatePdf(). Now, suppose client A wants to use the interface but he intends to use the reports only in PDF format and not in Excel format. Unnecessarily he will be forced to implement both methods. The ideal solution in this case will be to extend Reportable and create two interfaces PdfReportable and ExcelReportable.
D: Dependency Inversion Principle
Depend on abstractions, not on concretions.
- Design the application in such a way that various modules can be separated from each other using an abstract layer to bind them together.
eg: BeanFactory in Spring framework- High level modules should not depend on low level modules
- Abstractions should not depend on details. Details should depend on abstraction.
- With dependency inversion, we can test classes independently.
Beginner's Luck 