SOLID Design Principles Review
We look at the brief history behind the principles, see why it's so important to use SOLID principles in our daily designs, and dive into the details of the principles.
Join the DZone community and get the full member experience.Join For Free
In this article series, we will examine SOLID Design Principles: what are they, and what are they meant to do?
First of all, we will look at the brief history behind the principles; later on, we will see why it is so important to use SOLID principles in our day-day designs, and then finally we will dive into the details of the principles.
These five principles were first brought together and mentioned in the book 'Agile Software Development: Principles, Patterns, and Practices' by Robert C. Martin (Uncle Bob). Originally the principles were not abbreviated to SOLID. Micheal Feathers rearranged these principles and got SOLID from the first letters. Thus the SOLID principles were born. However, the contributors list of the principles is much more longer. Bertrand Mayer, Barbara Liskov, Kent Beck, Martin Fowler, and many others contributed to the principles.
After this little brief history:
If we ask the question why it is important to use these principles and what are the benefits. We can list the benefits as follows:
- Applying these principles; our code becomes much more maintainable and extendable because we prepare the code for possible future changes.
- Our design becomes less complex and more readable and understandable by other developers.
SOLID stands for below five design principles:
- Single Responsibility.
- Liskov Substitution.
- Interface Segregation.
- Dependency Inversion.
Single Responsibility Principle
The single responsibility principle simply states that each class(module, component, method, etc.) should have only one responsibility. There is no precise definition for 'responsibility' thus leading to a misunderstanding between developers. A more practical explanation for the single responsibility principle states that a class should have only one reason to change.
As an example we can use Bob Martin’s payroll application example: In this payroll application we have an employee class:
Here are the reasons to change for this class:
- The financial department may want to account for new types of employee benefits. In this case
calculateMonthlySalarywill be affected.
- The HR department may want to change the hours report format to comply with regulations.
produceMonthlyHoursReportwill be affected.
- The R&D department may want to change the database technology.
saveModificationsmethod will be affected.
So there are three reasons to change for this class, thus this breaks the single responsibility principle. When it breaks the single responsibility principle; it leads to strong coupling between components.
If we redesign our class to comply with the single responsibility principle we get four classes:
As you can see there is one class for each responsibility.
Employee class is keeping information related to only employees,
PaymentService class is responsible for calculating salaries,
WorkHoursService for preparing work hours reports and
EmployeeDAO class is for handling database communication.
The single responsibility principle is very vague. It is a tough task to decide the responsibility of a class. It is important to keep the balance when deciding the responsibilities. If we make one method containing classes everywhere, our design becomes a hell of classes. To keep the balance; we must pay attention to the high cohesion principle. Simply saying, things that change together should be together.
Opinions expressed by DZone contributors are their own.