SOLID Principles Explained
SOLID principles were first conceptualized by Robert C Martin in the year 2000 paper Design Principle and Design Patterns. Although it was Michael Feathers who introduced the SOLID acronym.
In Object-oriented programming, SOLID is an acronym for five design principles mainly intended to make software design more understandable flexible, and maintainable. — Wikipendia
The Principle is an acronym of the five principles given below in the image.
These principles will help us to reduce tight coupling between classes. Meaning a group of classes that are highly dependent on each other that should be avoided.
The detailed concept of each of these principles with examples
Let’s take the example of a customer who has visited a restaurant and wants to make payment. Here, what does the customer need?
- Bill Amount.
- Generated Report / detailed statement.
Let’s see how does the RestaurantExample class looks like if the billing calculation and generation of Invoice are in a single class.
Code smells in the above example
In the above code, there are different types of reports or detailed statements and the restaurant can generate customer requests. If in future a new type of report (EXCEL Report) can be generated by the restaurant then a new method named generateReportExcel in the RestaurantExample class will be added. Which will lead to retesting of the full class, maintaining a new method and the Number of lines of code in the class are concerning.
A class diagram for the above code mentioned below:
Class diagram after applying SOLID Principle on the given problem statement mentioned below:
Now, the role of the BillingService class:
The BillingService class has only one responsibility and only one reason to change that is to calculate the bill for the customer.
Hence, it can be called as a single responsibility principle (SRP).
Note: The Report Generation is not the Billing Service responsibility its the ReportingService responsibility. Which we will discuss further.
Single Responsibility (SRP)
Single Responsibility principle states that:
“A class should have only one reason to change.”
The benefit of having a Single Responsibility for each class will have very few test cases, fewer functionalities, less dependency, and easy to debug.
Next, Reporting Service, ReportGenerator Interface, and ReportContext.
The restaurant supports a set of report formats like PDF, XML, JSON, and CSV.
Now, Restaurant wants to enhance the existing functionality by introducing a new report generation feature named excelReport without causing any impact on the existing behavior and code.
This requirement change can be achieved easily only by introducing a new class called ExcelReport. Hence, it reduces the amount of time for development, unit testing, and system testing.
It means that the behavior of the module can be extended depending on the change in the requirement. But, extending the behavior of the module will not result in a change in the source or the binary code of the Module.
Open-Closed Principle
Open-Closed Principle states that:
“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”
Interface Segregation Principle
Interface Segregation Principle states that:
“The concrete class should not be forced to implement unwanted interfaces.”
As the above Class Diagram shows, the job of the ReportGenerator Interface is to provide an abstraction to generate a variety of reports on the request of the restaurant. The ExcelReport class can directly implement the abstraction of the ReportGenerator interface rather than having its own behavior. Also, the BillingService class can live independently with the ReportGenerator Interface.
Dependency Inversion Principle
Dependency Inversion Principle states that:
“The Higher Level Modules should not be directly dependent on the Lower level Modules or vice versa. But, the modules should be always dependent on its abstraction.”
With reference to the above Class Diagram shows, the ReportGenerator Interface context is injected into the ReportContext class via a constructor Injection. Were the ReportGenerator holds the type of report abstraction.
Liskov’s Substitution Principle
Liskov’s Substitution Principle states that:
“Any Object of some class in object-oriented programming can be substituted with an object of the child class.”
The link for the example can be found in GitHub mentioned below:
OR
Click here to access it.
Conclusion
SOLID Programming is a basic principle for the development of highly scalable, maintainable applications that avoids code smells. With the help of these principles, a developer should not try to reinvent the wheel rather implement it with already available and proven solutions.
