单一职责原则(SRP:Single responsibility principle)又称单一功能原则,你可能觉得这个原则很简单，听起来的确是这样，不就是一个类，只做一件事嘛？真的是这样吗？
这个原则的英文是：
There should never be more than one reason for a class to change.
它的中文意思就是，一个类，只能有一个变化的原因。
单一原则要求就是不要设计大而全的类，要设计粒度小、功能单一的类。换个角度来讲就是，一个类包含了两个或者两个以上业务不相干的功能，那我们就说它职责不够单一，应该将它拆分成多个功能更加单一、粒度更细的类。
单一职责优点如下：
降低类的复杂度
提高类的可读性
提高系统的可维护性
降低变更引起的风险
听起来很容易，但是有时候，如果要把单一职责原则正确的适用起来，就不是那么简单的了。
举个例子：
我们的手机有打电话的功能，打电话需要先接通，然后通信，最后挂断。那就是三个方法，用类图来表示就是：
在使用这个功能的时候，它可能会有哪些原因导致其变动？一是打电话的时候，它的通信连接协议可能会改变，二是通信的时候，通信协议有可能会改变，这就有两个导致这个类需要变更的原因了。
而这两个需要变更的原因中， 接通电话时候的通信连接协议的改变，是通信的时候通信所需要去关注的吗？并不需要，所以我们可以说这样的设计是违反单一职责职责的，我们应该对它进行职责拆分。
比如：
通过把一个类中，处理不同事情的业务，扩展到两个接口去实现，让一个类的职责单一。
因为通常我们都是面向接口编程，这样当一个接口改变的时候，影响的只对相应的实现类有影响，对其他接口无影响。
看了这个例子后，有没有反思，我以前的设计是不是有问题，不要怀疑，你没有问题，单一原则中最难的认定的就是职责划分，因为职责是一个模糊的概念，在实际开发中，想第一张图那样设计其实也没有问题，又很简单，就把打电话划分成一个职责。但从学术上来讲，这又是不规范的，所以单一职责原则在职责划分的时候，每个人划分的职责可能都是因人而异。
除了类中的单一职责，方法也因为遵循单一职责原则，比如
/*
* @description: 把参数字段的值修改，并存储到数据库
* @date 2022/2/22
**/
void changeUser(User user, String key, String value){
}更加传递的key不同，把user中对应的key修改成指定的value,千万不要这样写，这样的方法职责不明确，做的事情太多，bug就会在里面产生