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

there should never be more than one reason for a class to change.

我们知道，在面向对象设计中要做到高内聚低耦合。而单一职责原则就是实现高内聚低耦合的最好办法。面向对象设计中单一职责原则是指： 一个类只负责一个功能领域中的相应职责。
如果一个类承担的职责过多，就等于把这些职责耦合在了一起。当其中一个职责变化时，可能影响其他职责的运作。

这样的例子在设计中很常见，书中就给了一个很好的例子：调制解调器。这是一个调制解调器最基本的功能。但是这个类事实上完成了两个职责：连接的建立和中断、数据的发送和接收。显然，这违反了SRP。这样做会有潜在的问题：当仅需要改变数据连接方式时，必须修改Modem类，而修改Modem类的结果就是使得任何依赖Modem类的元素都需要重新编译，不管它是不是用到了数据连接功能。解决的办法，书中也已经给出：重构Modem类，从中抽出两个接口，一个专门负责连接、另一个专门负责数据发送。依赖Modem类的元素也要做相应的细化，根据职责的不同分别依赖不同的接口。最后由ModemImplementation类实现这两个接口。

从这个例子中，我们不难发现，违反SRP通常是由于过于“真实”地设计了一个类所造成的。因此，解决办法是往更高一层进行抽象化提取，将对某个具体类的依赖改变为对一组接口或抽象类的依赖。当然，这个抽象化的提取应该根据需要设计，而不是盲目提取。比如刚才这个Modem的例子中，如果有必要，还可以把DataChannel抽象为DataSender和DataReceiver两个接口。

另一个例子：

一个是有关几何计算方面的，另一个是有关图形方面的。对于前者而说，程序从来不需要绘制图形；而对于后者来说，程序也从来不需要计算图形的面积。
在上面这种情况下，我们的设计就违反了单一职责原则。它即提供了几何计算方面的功能，又提供了图形绘制方面的功能。这样，在有关几何计算方面的应用程序中就要链接图形显示方面的库文件；而在有关图形方面的应用程序中却链接了数学计算方面的库文件。而这些多余的链接其实是不必要的。它们不但会使编译、链接的时间变长，而且会使应用程序占用的内存增加。如果我们对图形的显示代码做了修改，那么有关几何计算方面的应用程序就要重新链接。我们为什么要为自己不需要的功能重新链接自己的程序呢？因此，上面的设计是不正确的。

转载请注明：于哲的博客 » 设计模式(3)：单一职责原则