What is SOLID?
SOLID stands for the first 5 letters of the 5 principles of object oriented design. Helps programmers write code that is easy to read, understand, and maintain. It was launched by Robert C. Martin and Michael Feathers. These 5 principles include:
- Single responsibility priciple (SRP)
- Open / Closed principle (OCP)
- Liskov substitution principe (LSP)
- Interface segregation principle (ISP)
- Dependency inversion principle (DIP)
In this article we will learn about the first principle of SOLID – Single Responsibility Principle (SRP) – The single principle.
Single Responsibility principle (SRP) – Single Responsibility
This principle corresponds to the letter S in SOLID, which means that a class should hold only one responsibility (function). Determine whether a class holds one or more responsibilities by considering that if more than one class-changing engine can be thought of, the class has more than one responsibility.
Why solitary?
Looking at the picture you see above are tools: pliers, hammers, saws, … and below is a versatile tool – a combination of the tools above. It looks like a versatile tool has everything and is very convenient, but let’s take a look at the disadvantages of using it:
- The multipurpose tool below is a combination of the above tools, but the performance is not equal: the saw, the hammer is too small, the ruler is too short, even though it looks like the handle of a pliers. again, there is no pliers to perform the screw function.
- When you want to perform a specific function like hammering, instead of just using a hammer, you will have to use a multi-tool with a bunch of tools combined, quite cumbersome.
- In the event that a part of the multi-tool is damaged or the requirement is changed: changing the gauge of the ruler, making the head smaller …, we will have to remove the whole part, only repair the damaged part. broken or altered and then reassembled, the maintain and extend becomes quite complicated.
=> Conclusion: Multipurpose tool is too bulky, complicated, difficult to maintain and extend.
In programming, too, a class with too many functions becomes cumbersome and complex. As the application evolved, continuously changing requirements resulted in code change. If a class has too many functions, it will be difficult to change, take more time to repair, and possibly affect other running modules. So, for easy maintenance and expansion in the future, you should design in a single direction: each class should be responsible for only one feature. If code occurs that does not belong to the responsibility of the class, it is advisable to separate that code into another processor class.
Apply
Take a look at an example student management program:
At first glance it seems quite normal, but in the near future, when the system is expanded, the functions will not be as simple as this anymore, we will need to add the function of calculating points, calculating fees … the class SinhVien will get bigger and bigger, if the code is difficult to read at the beginning, it may not be possible to continue developing it into a perfect program.
For more science, try using the Single Responsibility Principle for you. Divide SinhVien class into smaller classes, each class has a unique job, namely:
When dividing the Sinhvien class, when someone else looks at the project, it also feels scientific and easy to understand. Later, even if you upgrade a lot, it will be easier, short code will also have less bugs.
The separation of duties between classes makes the code much more clean, easy to read, maintainable and much more extensible. It will be easy to extend to new formats later, or also very easy to meet the requirement of more log export as the program expands.
Conclusion
In practice, the adoption of the SRP depends on application variation. If the application does change then the application of the SRP is necessary. If the application is not really changing but only the intention, then adopting the SRP can cause unnecessary complications.
SRP is the simplest principle to understand, but also the most difficult to apply correctly. We often naturally group responsibilities together, but in programming they need to find and separate responsibilities from each other.
References
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod https://en.wikipedia.org/wiki/Single_responsibility_principle https://nhungdongcodevui.com/2017/03/18/solid-la-gi-nguyen-tac- 1-don-nhiem-single-responsibility-principle / https://topdev.vn/blog/solid-la-gi/ https://viblo.asia/p/solid-single-responsibility-principle-nguyen-ly- don-nhiem-PaLkDmKMvlX https://tuanfadbg.com/single-responsibility-principle-nguyen-tac-don-trach-nhiem/