单一职责原则

单一职责原则

单一职责原则的定义是：应该有且仅有一个原因引起类的变更。

没错，单一职责原则就这一句话，不懂没关系，我们举个例子。

我们以打电话为例，电话通话的时候有 4 个过程发生：拨号、通话、回应、挂机。那我们写一个接口，类图如下：

代码为：

我们看这个接口有没有问题？相信大部分同学会觉得没问题，因为平常我们就是这么写的。没错，这个接口接近于完美，注意，是“接近”。单一职责原则要求一个接口或一个类只能有一个原因引起变化，也就是一个接口或者类只能有一个职责，它就负责一件事情，看看上面的接口只负责一件事情吗？明显不是。

IPhone这个接口包含了两个职责：协议管理和数据传送。dial 和 hangup 这两个方法实现的是协议管理，分别负责拨号接通和挂机，chat 方法实现的是数据传送。不管是协议接通的变化还是输出传送的变化，都会引起这个接口的变化。所以，IPhone这个接口并不符合单一职责原则。若要让IPhone满足单一职责原则，我们就要对其进行拆分，拆分后的类图如下：

这样设计就完美了，一个类实现了两个接口，把两个职责融合在一个类中。你会觉得这个Phone有两个原因引起变化了啊，是的，但是别忘了我们是面向接口编程，我们对外公布的是接口而不是实现类。

另外，单一职责原则不仅适用于接口和类，也适用于方法。一个方法尽可能只做一件事，比如一个修改用户密码的方法，不要把这个方法放到“修改用户信息”方法中。

单一职责的好处

1. 类的复杂性降低，实现什么职责都有清晰明确的定义；

2. 可读性高，复杂性降低，可读性自然就提高了；

3. 可维护性提高，可读性提高了，那自然更容易维护了；

4. 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

如果对你有帮助，就一键三连呗（点赞+收藏+关注），我会持续更新更多干货~~