单一职责原则（SRP）

单一职责原则（Single Responsibility Principle  |  SRP）

单一职责原则，用来指导接口、类甚至是方法的设计。其实，对于接口和方法，实现单一职责是比较简单的，对于类，在实际情况中，很难做到单一职责。

什么是职责？

单一职责原则，从字面意思上来看，这个原则的核心就是职责，那究竟什么是职责？我个人的理解就是“你负责的部分”；比如在流水线上工作的人，每个人在自己的岗位上都有自己的工作，这个岗位的工作，就是这个岗位的职责。

单一职责的定义

书面的解释：有且仅有一个原因引起类的变更。
怎么理解这句话呢，还拿流水线上的人举例子，对于流水线上的每一个人，它们的职责（工作）都是单一的，假设第一个人的工作是往流水线上放零件，他之后的人一步一步的加工，可能第二个人的职责就是拧一个地方的螺丝，除了干这件事，其他的不归他管。如果第二个人的工作变了，原因只是他负责的第二步工作发生了改变，这符合单一职责的定义。
假设一个流水线上只有一个人，他负责所有的工作，那么，引起他工作改变的原因就不止一个，生产产品过程中的所有的步骤，都是改变他的原因，因此，这种情况下不符合单一职责的定义。

举栗子

电话通话

电话通话的过程，可以分解为三个操作：拨号、交流、挂断。因此，可以设计如下的接口

public interface Iphone{ //这里的Iphone中的I是interface的意思，这里不是IPhone手机...
    //拨号
    public void dial(String phoneNumber);
    //交流
    public void chat(Object o);
    //挂断
    public void hangup();       
}  

分析一下这个接口符不符合单一职责原则呢？这个接口不符合单一职责原则，因为它负责了两件事，通信协议管理（dial()方法和hangup()方法）,以及数据传送(chat()方法)。如果它的通信协议和数据传送都有变化（它两就是上面定义中的“引起变化的原因”），那么Iphone的实现类都要进行相应的修改，所以，不符合单一职责原则。

从这个例子中看到，单一职责最大的优势就是最少的改动，如果代码要进行整改，采用单一职责的原则，可以使得代码的改动更少。

因此，采用单一职责原则修改上面的例子，使用UML图表示修改后的结果：

                                                 

对于通信协议和数据传送这两个职责，分别设计接口，然后将它们的实现类组合到Phone。这就是单一职责原则的设计方式，如果通信协议发生改变，则修改通信协议的实现类；如果数据传送发生改变，则修改数据传送的实现类，对于类Phone来说，他只是调用接口的方法，如果不添加新的功能，对于“打电话”这个功能来说，Phone的代码不用进行任何修改。但是又引入了新的问题：增加了类之间的耦合程度，和类的复杂性，这显然是不希望看到的，因此，可以使用实现的方式降低复杂性和耦合度（如下图）。

                                 

可以看到，通过修改，Phone类又不符合单一职责的原则。但是通过使用面向接口的编程（简单来说就是用一个接口类型的引用变量接受它的实现类的对象），对外提供接口的方式，和上面采用的组合方式有类似的效果。

总结

使用单一职责原则对类进行设计，并不容易

主要从类、接口和方法三方面来看单一职责原则：

通过上面的例子来看，仅仅是一个打电话，使用真正的单一职责原则，也是很复杂的，在项目开发的过程中，类的设计往往不是单一职责的。但是，对于接口的设计，一定要采用单一职责的原则。对于方法来说，也要做到职责单一。比如说，要修改一个User对象的信息，不要使用一个changUser()方法来修改所有的属性值，例如，修改用户名就用changUserName()，而不是调用统一的changUser()方法，通过参数指定修改的字段。

单一职责原则的优势

• 类的复杂性降低，职责单一
• 因为类的复杂性降低，所以可读性提高
• 因为可读性提高，所以可维护性提高
• 降低变更引起的风险，这一点在上面的例子中也说过了，对于需要变更时，只需要修改实现它的类即可，越少的改动，引发错误的概率就越低。