1、单一职责原则的概念
Single Responsibility Principle，SRP：
一个类被改变的原因不能超过一个，也就是说，一个类只有一个职责，如果职责过多，代码就会臃肿，可读性更差，也更难以维护。其实上单一职责原则和接口隔离原则有一定的关系，接口隔离以后，职责就单一了，实现这个接口的类的职责自然也就单一了。但是接口隔离关注的是抽象层，单一职责关注的是两者兼而有之，偏重于实现。
2、为什么要遵守单一职责原则
1、提高类的可维护性和可读写性
一个类的职责少了，复杂度降低了，代码就少了，可读性也就好了，可维护性自然就高了。
2、提高系统的可维护性
系统是由类组成的，每个类的可维护性高，相对来讲整个系统的可维护性就高。当然，前提是系统的架构没有问题。
3、降低变更的风险
一个类的职责越多，变更的可能性就更大，变更带来的风险也就越大，
3、如何遵守单一职责原则
合理的职责分解
相同的职责放到一起，不同的职责分解到不同的接口和实现中去，这个是最容易也是最难运用的原则，关键还是要从业务出发，从需求出发，识别出同一种类型的职责。举个例子：人的行为分析，包括了生理、生活和工作等行为的分析，生理行为包括吃、跑、睡等行为，生活行为包括穿衣等行为，工作行为包括上下班，开会等行为，如下图所示：
图1 人类行为分析示例
人类的行为分成了三个接口：生理行为接口、工作行为接口和生活行为接口，以及三个实现类。如果都用一个实现类来承担这三个接口的职责，就会导致代码臃肿，不易维护，如果以后再加上其他行为，例如学习行为接口，将会产生变更风险（这里还用到了组合模式，以后会详细说明）。
四、最佳实践
在实际工作中，有一个经常会用到的设计模式，DAO模式，又叫数据访问对象，里面定义了数据库中表的增、删、改、查操作，按照单一职责原则，为什么不把增、删、改、查分别定义成四种接口？这是因为数据库的表操作，基本上就是这四种类型，不可能变化，所以没有必要分开定义，反而经常变化的是数据库的表结构，表结构一变，这四种操作都要跟着变。所以通常我们会针对一张表实现一个DAO，一张表就代表一种类型的职责。