面向对象设计原则之单一职责原则

只有佛自己应当担负起公布玄妙秘密的职责 -- <英语典故字典>

单一职责原则（Single Responsibility Principle）

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

什么是职责

在SRP中，我们把职责定义为“变化的原因”。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。单一职责的运用难点就在于职责的划分。下面根据调制器代码进行简单说明：
Modem.java -- 方法级别违背单一职责

public interface Modem{
    public void dial(String pno);
    public void hangup();
    public void send(String data);
    public void recv();
}

该接口显示出两个职责，第一个是连接管理，第二个是数据通信。dial()和hangup()进行调制解调的连接处理，send()和recv()进行数据通信。
这两个职责应该分开吗？这依赖于应用程序变化的方式。如果应用程序的变化会影响连接函数的签名，那么这个设计就会具有僵化的臭味，因为调用send和recv类必须要重新编译，部署的次数常常会超过我们希望的次数，在此情况下，这两个职责应该被分离，此时在方法级别违背了单一职责原则。
如果应用程序的变化方式总是导致这两个职责同时变化，那么就不必分离它们，分离它们就会具有不必要的复杂性的臭味。
极端的违背单一职责
public interface Modem{
public void modem(String pno);
}
调试方法中包括了调制解调的连接处理和进行数据通信，此时在代码级别违背了单一职责，设计具有僵化的臭味。

遵循SRP的优点

1. 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
2. 提高类的可读性，提高系统的可维护性；
3. 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

结论

SRP是所有原则中的最简单的之一，同时也是最难正确运用的之一。难点就在与职责的划分上与场景的变化导致职责的扩散，我们会自然的把职责结合在一起。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。

内容借鉴于---《敏捷软件开发 原则、模式与实践》