六大设计原则之单一职责原则

英文名称：Single Reponsibility Principle(简称SPR)

定义：应该有且仅有一个原因引起类的变更。

举例：

单一职责原则要求一个接口或类只有一个原因引起变化，也就是一个接口或类只有一个职责。但IPhone这个接口包含了两个职责：一个是协议管理（dail、hangup方法）、一个是数据传送（chat方法）。协议接通的变化、数据传送的变化都会引起接口或实现类的变化。

图1-6的设计才是合理的，一个类实现了两个接口，把两个接口的职责融合在一个类中。

好处：

• 类的复杂性降低
• 可读性提高
• 可维护性提高
• 变更引起的风险降低

难点：

1. 单一职责原则最难划分的就是职责。
2. 实际项目中定义一个IPhone接口也没有错，但是纯从“学究”理论上分析就有问题了。
3. 用“职责”或“变化原因”来衡量接口或类，但两者都是不可度量的，因项目而异，因环境而异。

扩展：

单一职责原则同样适用于方法。一个方法尽可能做一件事，比如一个方法修改用户密码，不要把这个方法放到“修改用户信息”方法中，这个方法的颗粒度很粗。

最佳实践：

接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

个人感悟：

接口、类的设计常常没有遵循单一职责原则。

一些业务方法会尽量遵循单一职责原则，尽量保证方法只做一件事，这样的好处是当业务发生变更时，可快速重构原有方法。

一些基类的方法，为了提高复用性，且往往很确定在未来变更（即使业务发生变更）的可能性不大时，会设计一个通用的方法。比如baseDao.findByCriteria(T criteria)，其中criteria是一个泛型变量，可传入任意字段进行条件查询。