概念
单一职责原则（SRP：Single responsibility principle）又称单一功能原则，它规定一个类应该只有一个发生变化的原因。通俗来讲就是 一个类或模块应该有且只负责一件事。
为什么，因为假如负责了2件事，任何一件事需要改变就引起了该模块的改变，违反了 “一个类应该只有一个发生变化的原因”。所以就可以简单的理解为就是 一个类或模块细分到只负责一个功能，这就要求了这个类不能太臃肿，要简单精细。
问题由来
有一个类T负责两个不同的职责：职责P1和职责P2。当因为职责P1的需求发生改变而需要修改类T的时候，有可能会导致原本运行正常的职责P2功能发生故障。
比如一个查询学生信息类，StudentBiz，里面有getDBConnetion()，selectStudentList(),selectStudentOne(), 如果需要修改获取数据库连接，由oracle改为mysql，可能会影响到获取student信息。
产生原因
每个人都清楚要写出高内聚低耦合的程序，但是很多耦合常常发生在不经意之间，其原因就是职责扩散，因为某种原因，某一职责被分化为颗粒度更细的多个职责了。
比如查询学生信息类中，可能起初只是为了方便，所有的功能写在一个方法中，建立连接，查询，返回，展示等，后来优化了，提取出来几个方法。
解决方案
遵循单一职责原则，分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1的时候，不会使职责P2发生故障风险。同理，当修改T2的时候，也不会使职责P1发生故障风险。
比如：抽取出DBUtils，专门处理数据库的连接等；抽取出StudentService，专门查询学生信息；StudentBiz就专门处理学生相关信息的业务，比如是查询多个，还是单个，还是其他。
编者按
说到单一职责原则，其实大家都很容易理解，因为它相对还是太简单了，但是具体到实践中，又感觉力不从心，毕竟这不是一个1+1=2，很确定的东西，具体问题还要具体分析，合适才是最好的。稍有经验的程序员即使没有专门学习过这个单一职责原则，在设计软件或者开发功能的时候也会自觉遵守这个重要原则，因为这是一个基本的常识，编码的规范。在软件编程中，谁也不希望因为修改了一个功能从而引入其他的功能发生故障。但是即使这样，大家还是会在无形中违背这一设计原则,出现不合理的代码，这是职责扩散导致的就是因为某种原因，职责P1被分化为粒度更细的职责P1和P2。比如功能的实现从初始到逐渐的优化过程中。
但是
适当地违背单一职责原则有时候并不是坏事，凡事并不是绝对的，这样做反而能提高开发效率，易于理解，所以还是要按照实际需求来选择使用。
比如：刚才拆解的StudentService中有selectStudentList(),selectStudentOne()，那是不是就有人说再拆分成两个类，一个查单个，一个查列表，这就没必要了，按照大家的认知，再结合分层结构，service层就可以按照类别student来处理相关的原子服务了，没必要再把每个原子服务再拆分，反而显得不合理了。
总结
单一职责原则需要我们：
1、尽可能细分我们的功能，单一化，低耦合，但是不是绝对的；
2、降低风险引入，避免风险扩散；
3、横向和纵向相结合，合理的拆分。
