浅析设计模式-单一职责原则
单一职责原则的英文名称是 Single Responsibility Principle，简称SRP。
定义
应该有且仅有一个原因引起类的变更。也就是说，一个类应当只有一个职责，如果类的职责过多，代码就会臃肿，可读性变差，也难以维护。单一职责原则和接口隔离原则有一定的关系，接口隔离之后，职责也就单一了，实现这个接口的类的职责自然也就单一了。但，接口隔离关注的是抽象层，单一职责关注的偏重于实现。
遵守单一职责的好处
- 提高类的可维护性和可读写性： 一个类的职责少了，复杂度降低了，代码就少了，可读性也就好了，可维护性自然就高了。
- 提高系统的可维护性： 系统是由类组成的，每个类的可维护性高，相对来讲整个系统的可维护性就高，当然是以系统架构是没问题为前提。
- 降低变更的风险： 一个类的职责越多，发生变更的可能性就越大，变动的越频繁，内部逻辑越复杂，出现事故的概率也就越大。
如何遵守单一职责原则
合理的职责分解
相同的职责放在一起，不同的职责分解到不同的接口和实现中去，这个是最容易也最难运用的原则，关键还是从业务需求出发，识别出同一种类型的职责。
以订单系统举例。
订单系统关注点在于订单的状态的变化与订单强相关的数据。当一个采购订单生成后，物资是未发货，还是已入库，订单系统并不关心，这些数据应当是由物流系统提供。
如果将物流的数据也由订单系统维护，那么订单系统的职责也就不再单一，订单系统的范围将会无限蔓延。最终系统也就无法维护了。
四、最佳实践
在实际工作中，有一个经常会用到的设计模式，DAO模式，又叫数据访问对象，里面定义了数据库中表的增、删、改、查操作，按照单一职责原则，为什么不把增、删、改、查分别定义成四种接口？这是因为数据库的表操作，基本上就是这四种类型，不可能变化，所以没有必要分开定义，反而经常变化的是数据库的表结构，表结构一变，这四种操作都要跟着变。所以通常我们会针对一张表实现一个DAO，一张表就代表一种类型的职责。
注意：单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而已，因环境而异。