参考文章：https://blog.csdn.net/zhengzhb/article/details/7278174
参考书籍：设计模式之禅 --- 秦小波 著
定义：应该有且只有一个原因引起类的改变
一句话描述：当类只有一个作用时，改变这个类的原因也只有一个，即一个类只负责一类职责。
代码重现：
public interface IUserDao {
int serUserName(String UserName);
String getUserNameById(String UserId);
int setUserPassword(String Password);
String getUserPasswordById(String UserId);
boolean updateUserPassword(String Password);
boolean deleteUser(User user);
}
public class UserDao implements IUserDao {
省略........
}
现在有一个IUserDao 接口，这个接口有两个职责，一个是负责User的属性T1，一个是负责User 的行为T2。显然，对于一般程序员来讲，都不会这样设计，没有正确的将业务逻辑与业务对象正确区分。这样的设计结果会导致一个类（接口）信息杂糅，让代码管理陷入混乱。比如当T1发生改变时，那么IUserDao 需要修改；同样，T2变化时，IUserDao 依旧需要修改。T1，T2的变化本来没有直接影响的，但是有间接影响：T1变化导致IUserDao 的修改，有可能会导致T2发生故障风险，毕竟两者是在同一个类中。
问题产生:
IUserDao接口中有T1和T2两个职责。任意一个职责的改变，都会对IUserDao产生变化，这个变化最终有可能导致另一个职责发生故障风险。
问题解决：
为了避免上述问题的产生，应该将IUserDao中的T1和T2职责分开，单独放在不同的接口中，分别实现其职责，这样两者修改时，并不会接触到另一个职责的代码，从而彻底消除影响。
所以上述代码重新拆分：
User行为接口 IUserBiz：
public interface IUserBiz {
boolean updateUserPassword(String Password);
boolean deleteUser(User user);
}
User属性接口 IUserBo：
public interface IUserBo {
int serUserName(String UserName);
String getUserNameById(String UserId);
int setUserPassword(String Password);
String getUserPasswordById(String UserId);
}
当User的属性职责（IUserBo）发生改变时，并不会影响到行为职责（IUserBiz）。
可能有人要问：IUserBo是只有一个原则：User属性职责；IUserBiz是只有一个原则：User行为职责，但是UserDao却有两个原则：属性职责和行为职责，这样也是符合单一职责原则吗？
其实这样想也有道理，但是不要忘了，我们是面向接口编程，我们对外公布的是接口，而不是具体的实现类，并且若一定要实现接口和类的单一职责原则，那么我们就需要在 IUserBo 和 IUserBiz 与UserDao 上再加一个各自接口的实现类UserBo，UserBiz，然后在UserDao使用组合，这样就完全满足单一职责原则的要求。这样写带来的后果是强耦合（组合是一种强耦合的关系），类的复杂性提高，数量增加，完全就是为了设计而设计。
通过上面的例子，我们来总结一下单一职责原则有什么好处：
①类的复杂性降低，实现什么原则都有清晰明确的定义；
②可读性提高，复杂性降低；
③可维护性提高；
④变更引起的风险降低；
建议：接口一定要做到单一职责，类的设计尽量做到只有一个原因引起的变化
