基本概念
单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。
There should never be more than one reason for a class to change.
实例说明
简单栗子感受一哈 看如下类图
分析一下这个类图哈，UserInfo实现IUserInfo接口，IUserInfo接口下有一系列方法，不过认真看一下这些方法，结合让你直接定义一个UserInfo类，很容易会发现username、password、userID会被我们作为类的属性，其他的会被作为类的行为。这样设计接口就不满足原则了。
可拆分为以下类图
分析一哈这个类图，仅将原来的一个接口泛化，即IUserInfo接口继承了两个接口，…………这些仅起到说明的作用，其他和上述类图类似，不详细说明了。
在看以下这个类图，多了一个依赖关系，这种设计就符合单一职责原则
以上我们把一个接口拆分成两个接口的动作，就是依赖了单一职责原则，那什么是单一
职责原则呢？单一职责原则的定义是：应该有且仅有一个原因引起类的变更。
复杂栗子感受一哈
分析一下这个类图哈，定义了一个电话的接口，有打电话、通话、挂断这三个方法，正常我们开发可能就写成这样子了，但是我阅读的这书中，却提出了这里面包含了协议管理和处理数据两个职责，分别对应打电话、挂断电话和通话，细想一下，确实可以如此，毕竟拨电话和挂电话不涉及到数据处理，仅需协议匹配就可连接、断开。
所以也得拆分一下，得到如下类图
优缺点
单一职责原则的好处
● 类的复杂性降低；
● 可读性提高；
● 可维护性提高；
● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助；
●单一职责适用于接口、类，同时也适用于方法。比如你的某个方法需要进行弹窗，且对应弹窗内还有其他逻辑处理，这时候我们就应该遵循单一职责原则，将处理回调的过程从弹窗方法内抽出来，保证弹窗的方法仅执行弹窗。
单一职责原则的缺点
● 职责难以划分；
● 受项目工期、成本、人员技术水平、硬件情况、网络情况等过多因素影响；
写在最后
结合已有项目分析
方法一定要做到单一职责原则，那样你代码的可读性、规范性会高一点，至少不low
接口和类尽量做到单一职责原则，举个栗子，上述电话的接口，虽然分离才能符合单一职责原则，但有时候我们的项目中就是这么写的，然后类进行实现。这块呢，需要项目的积累，我就不多说了
来源：CSDN
作者：月薪低于10k不改名
链接：https://blog.csdn.net/weixin_38703938/article/details/92624375