单一职责原则

一、什么是职责

在《敏捷软件开发：原则、模式与实践》中，把职责定义为变化的原因：如何你能想到多于一个动机去改变一个类，那么这个类就具有多于一个的职责。

就一个类而言，应该仅有一个引起它变化的原因。

二、单一原则的示例

 public interface IPhone {
    // 拨打电话
    public void dial(String phoneNumber);
    // 通话
    public void chat(Object o);
    //挂断电话
    public void hangup();
}

表面上看，这个接口似乎没有什么问题，简单描述这个接口的职责就是打电话，而且这三个方法也是和打电话相关的。不过细细分析，还是有问题的。单一职责原则要求一个接口或类，仅有一个引起它变化的原因。也就是一个接口或类只负责一件事，但是上面接口却负责了两件事情。一个是协议管理，一个是数据传输。dial()和hangup()实现的是协议管理，分别负责拨号接通和挂机。chat()实现的是数据的传输。协议和数据传输的变化都会引起这个接口和实现类的变化，但是这两个职责互相并不影响，所以考虑拆分为两个接口。

但似乎有人说这样Phone不就不满足单一职责原则了么，应该这样才算满足单一职责原则：

这样的话，一个手机类需要把ConnectionManager和DataTransfer组合起来才能使用，组合是一种强耦合关系，这样会导致类之间耦合过重，类的数量增加，人为的增加了设计的复杂性。

总结

使用单一职责原则的好处：
1）降低了类的复杂度；
2) 提高类的可读性，提高系统的可维护性;
3) 降低变更引起的风险(降低对其他功能的影响)

个人感想

感觉其实在日常项目中，有时候很难完全完全做到，就拿Java语言来说，一个类可以实现多个接口，那么这个类就已经不符合单一职责原则了。还有一个我们日常最常见违反单一职责原则的例子就是单例模式，单例模式的职责有三个：
1、 某一个类只有一个实例。
2、它必须自行创建这个实例。
3、它必须向整个系统提供这个实例。
但是到目前为止，这也导致了编程中需要结合场景来考虑是否需要遵守单一职责原则。
在《设计模式之禅》的作者也说，单一职责提出了一个编写程序的标准，用“职责”或“变化的原因”来衡量接口或类设计的是否优良，但是“职责”和“变化的原因”都是不可度量的，因项目而异，因环境而异。作者最后的建议是，接口一定要做到单一职责原则，类尽量做到只有一个原因引起变化。