Single Responsibility Principle of Software Design Principles

Single responsibility principle (SRP: Single responsibility principle) is also known as the single function principle. You may think this principle is very simple. It sounds like this. Isn't it just a class that only does one thing? Is it really?

The English language of this principle is:

There should never be more than one reason for  a class to change.                        

Its Chinese meaning is that a class can only have one reason for change.

The single principle requirement is not to design large and comprehensive classes, but to design classes with small granularity and single function. In other words, if a class contains two or more functions that are not related to business, then we say that its responsibilities are not single enough, and it should be split into multiple classes with more single function and finer granularity.

The advantages of single responsibility are as follows:
Reduce the complexity of
the class Improve the readability of the class
Improve the maintainability of the system
Reduce the risk caused by changes 

It sounds easy, but sometimes it's not that simple to apply the Single Responsibility Principle correctly.

for example:

Our mobile phones have the function of making calls. To make a call, we need to connect first, then communicate, and finally hang up. That's three methods, represented by a class diagram:

When using this function, what are the possible reasons for it to change? One is that when making a call, its communication connection protocol may change, and the other is that when communicating, the communication protocol may change. There are two reasons why this class needs to be changed.

Among these two reasons for needing to be changed, is the change of the communication connection protocol when the phone is connected, is the communication need to pay attention to when communicating? No, so we can say that such a design violates single responsibility and we should split responsibility for it.

for example:

 By extending the business of handling different things in one class to two interfaces to implement, the responsibility of a class is single.

Because we are usually interface-oriented programming, so when an interface changes, it only affects the corresponding implementation class, and has no effect on other interfaces.

After reading this example, do you have any reflections on whether there is a problem with my previous design? Don’t doubt, you have no problem. The most difficult thing to identify in a single principle is the division of responsibilities, because responsibilities are a vague concept, in actual development , it's not a problem to design like the first picture, and it's very simple, so the phone call is divided into a responsibility. However, academically speaking, this is not standardized, so when the single responsibility principle is divided into responsibilities, the responsibilities divided by each person may vary from person to person.

In addition to the single responsibility in the class, methods also follow the single responsibility principle, such as

  /*
     * @description:  把参数字段的值修改,并存储到数据库
     * @date 2022/2/22
     **/
    void changeUser(User user, String key, String value){
        
    }

The key passed is different. Change the corresponding key in the user to the specified value. Don't write it like this. The responsibility of such a method is not clear, and there are too many things to do, and bugs will occur in it.

Guess you like

Origin blog.csdn.net/qq_45171957/article/details/123057967