Single Responsibility Principle: A class or module should only do one thing
Article directory
1. Meaning
The Single Responsibility Principle (Single Responsibility Principle) is a principle in object-oriented programming, which requires that a class or module is only responsible for completing an independent function or task. In layman's terms, a class or module should only do one thing , and do it well.
The core function is to reduce the degree of coupling between programs, thereby enhancing readability, maintainability, scalability, reusability, and improving development efficiency.
2. Follow the value
1. Code clarity and readability
When a class or module is only responsible for completing an independent function, the responsibility of the code becomes clear and unambiguous . This makes the code easier to read and understand , improving the readability of the code . Other developers can quickly understand what it does and does when they look at the code. (Clear and readable for easy collaboration)
2. Code maintainability
A class or module is only responsible for a specific task. When we need to modify a certain function or fix a bug , we only need to focus on a specific class or module without worrying about affecting other parts of the code. This reduces the risk of modifying the code , simplifies the maintenance work, and improves the maintainability of the code. (Narrow the scope of concern, reduce coupling, reduce the scope of influence of the code, and reduce the possible risks of modification)
3. Code scalability
Code that follows the Single Responsibility Principle is easier to extend when the system needs to add new features or modify requirements . Since the responsibilities of each class or module are clear , we can modify and extend specific classes or modules without affecting other parts of the code. This is conducive to the evolution and expansion of the system, and improves the scalability of the code. (Clear responsibilities, low coupling, small scope of influence, easy to expand)
4. Code reusability
Code that follows the Single Responsibility Principle is generally more reusable. When a class or module is only responsible for a specific function, it can be reused by other modules or systems when that function is needed. This can reduce repeated writing of codes with similar functions, improve code reusability, and also help reduce redundant codes in the system. (Low coupling, minimized closed loop, low probability of redundant code when reused)
5. Improve development efficiency
The single responsibility principle can improve development efficiency. Due to the clear code responsibilities, good readability, and easy maintenance and expansion , developers can understand and modify the code more quickly during the development process, reducing development time and debugging time, and improving development efficiency.
3. Disadvantages
1. The number of classes or modules increases
Following the Single Responsibility Principle often requires splitting functionality into multiple independent classes or modules, which can lead to an increase in the number of classes or modules . If you split too much, there may be too many small classes or modules in the system, which increases the complexity of the code and the cost of maintenance. Therefore, in practice, the degree of splitting needs to be weighed to avoid problems caused by excessive splitting. (There are too many classes or modules, and it is cumbersome to write code, so pay attention to moderate splitting)
2. Increased complexity of cross-class or module collaboration
When splitting functionality into different classes or modules, more collaboration and interaction may need to be introduced. This may increase dependencies between codes, leading to increased complexity of the system. If responsibilities are not properly divided, it can lead to excessive interaction and communication, making the code difficult to understand and maintain. (Following the principle of single responsibility leads to relatively small "parts" split from the system, and the realization of a function may depend on multiple small "parts", which must increase the coupling and complexity of the program. In addition, each person is right The understanding of "single responsibility" is different. Some people think that steaming steamed buns is a responsibility, and some people think that kneading noodles, boiling water, and putting the steamer are all one responsibility, and there is a deviation in the understanding of the division of granularity)
3. Need more design and abstraction
To follow the Single Responsibility Principle requires more careful design and abstraction. This requires more time and effort to define class responsibilities and interfaces, and handle relationships between classes. This may increase the complexity of development and the difficulty of design. (Increasing the complexity of system design simply means that during system development, more time needs to be spent considering how to properly use the single responsibility principle and how to achieve "proper" splitting.)
4. May lead to over-design
Excessive splitting of functions and class responsibilities in pursuit of the single responsibility principle may lead to over-design of the system. If a function itself is not complicated, but too many classes and abstractions are introduced in order to meet the single responsibility principle, it may make the code redundant and complicated, and increase the maintenance cost of the system. (If it is an infinitely small split, then the complexity of the program is too great!)
4. Best Practices
1. Determine the responsibilities of the class or module
During the design process, carefully consider the responsibilities of each class or module to ensure that it is only responsible for completing an independent function or task. Responsibilities should be clear, specific and quantifiable , avoiding vague and overlapping responsibility definitions. (single responsibility, clear function)
2. High cohesion
High cohesion (High Cohesion) is a principle in object-oriented programming, which means that the members (methods and attributes) inside a class or module are closely related logically, and they all revolve around completing a specific function or task. In short, high cohesion means that a class or module should only do one thing , and do it well.
Each class or module should have high cohesion, that is, the members and methods inside the class should be closely related to the responsibilities of the class. The member variables and methods in the class should have a clear purpose and association, and should not contain content irrelevant to their responsibilities. (High cohesion, a class or module should only do one thing, the attributes and methods in the class are closely related to the functions to be realized, and do not contain irrelevant content)
3. Keep classes simple
Each class or module should be kept as simple as possible and not take on too many functions. If a class becomes large and complex, it may mean that it violates the Single Responsibility Principle. In this case, consider breaking the functionality into smaller classes or modules, each class responsible for only one clear functionality. (Simple class, only responsible for one function)
4. Moderate abstraction and interface definition
When demarcating the responsibilities of a class, the moderate use of abstractions and interfaces can provide flexibility and extensibility. By defining appropriate interfaces, the degree of coupling between classes can be reduced, and the maintainability and scalability of the code can be enhanced. But avoid excessive abstraction and interface definition, so as not to introduce unnecessary complexity. (moderate abstraction, reduce coupling)
5. Unit testing support
Following the Single Responsibility Principle facilitates unit testing. Each class or module is responsible for only one specific functionality, so it is easier to write unit tests for that functionality. This helps improve code quality and stability. (single function => unit test)
6. Review and refactor
Regularly review the code and do any necessary refactorings to ensure that the code still adheres to the Single Responsibility Principle. As the requirements change and the system evolves, the responsibilities of the code may change, so the code structure needs to be adjusted and refactored in time. (I think refactoring is very great. Many times I look back at the code I have written and find that the things I wrote are so bad. Of course, sometimes I find that I am so smart. It is very important to review the code and refactor It is useful and can quickly improve your coding level. In addition, the refactoring is partly due to the fact that there are fewer functional modules involved at the beginning of the development. As the development continues, it gradually has a broader vision and can Make some abstractions for some common content)