第8章 SRP：单一职责原则
一个类应该只有一个发生变化的原因。
8.1 定义职责
在SRP中我们把职责定义为变化的原因。如果你想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。同时，我们很难注意到这一点。我们习惯于以组的形式去考虑职责。违反SRP的示例代码：
public interface Modem
{
public void Dial(string pno);
public void Hangup();
public void Send(char c);
public char Recv();
}
大多数人会认为这个接口看起来非常合理。该接口所声明的4个函数确实是调制解调器所具有的功能。
然而接口中却显示出两个职责。第一个职责是链接管理；第二个职责是数据通信。dial和hangup函数进行调制解调器的连接处理，而send和recv函数进行数据通信。
这两个职责应该分开吗？这依赖于应用程序变化的方式。如果应用程序的变化会影响连接函数的签名（signature），那么这个设计就具有僵化性的臭味，因为调用send和recv的类必须要重新编译、部署的次数常常会超出我们希望的次数。在这种情况下，这两个职责应该被分离。这样做避免了客户应用程序和这两个职责耦合在一起。
另一方面，如果应用程序的变化方式总是导致这两个职责同时变化，那么就不必分离它们。实际上，分离它们就会有不必要的复杂性的臭味。
在此还有一个推论。仅当变化发生时，变化的轴线才具有实际意义。如果没有前兆，那么应用SRP或者任何其他原则都是不明智的。
8.2 分离耦合的职责
上图中，我把两个职责都耦合进了ModemImplementation类中。这不是所希望的，但是或许是必要的。常常会有一些和硬件或者操作系统的细节有关的原因，迫使我们把不愿耦合在一起的东西耦合在一起。然而，应用的其余部分来说，通过分离它们的接口我们已经解耦了概念。
我们可以把ModemImplementation类看作是一个杂凑物，或者有缺陷的类。然而，请注意所有的依赖关系都是从它发出的。谁也不需要依赖于它。除了main外，谁也不需要知道它的存在。因此，我们已经把丑陋的部分隐藏起来了。其丑陋性不会泄漏出来，污染应用的其他部分。
8.3 持久化
上图展示了一种常见的违反SRP的情形。Employee类包含了业务规则和对于持久化的控制。这两个职责在大多数情况下绝不应该混合在一起。业务规则往往会频繁地变化，而持久化的方式却不会如此频繁地变化，并且变化的原因也是完全不同的。把业务规则和持久化自系统绑定在一起的做法是自讨苦吃。
幸运的是，测试驱动的开发实践常常会远在设计出现臭味之前就迫使我们分离这两个职责。然而，如果测试没有迫使这种分离，而僵化性和脆弱性的臭味又很强烈，那么就应该使用FACADE（外观）、DAO（数据访问对象）或者PROXY（代理）模式对设计进行重构，分离这两个职责。
8.4 结论
SRP是所有原则中最简单的原则之一，也是最难正确运用的原则之一。我们会自然地把职责结合在一起。软件设计真正要做的许多工作，就是发现职责并把那些职责相互分离。事实上，我们将要论述的其余原则都会以这样或那样的方式回到这个问题上。
摘自：《敏捷软件开发：原则、模式与实践(C#版)》Robert C.Martin Micah Martin 著
转载请注明出处：