单一职责原则(SRP: Single Responsibilit

2018-02-24 本文已影响0人 brackenbo

这里的所有观点摘抄自《敏捷软件开发原则、模式与实践》，原著Robert C. Martin，邓辉等译。

职责分离

如果一个类承担的职责过多，就等于把这些职责都耦合在了一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。

类比于人，一个拥有多个角色的人，假如他既要。。。

例如书中的Retangle类，就具有绘制矩形和计算矩形面积的功能。图中可以看出，这两个功能分别由不同的应用来使用。

Screen Shot 2018-02-23 at 2.49.13 PM.png

如果我只是一个计算矩形面积的程式，并没有图形界面，理论上不需要引入绘制图形的GUI库（GUI的库一般比较大并且有很多依赖）。但是由于Retangle类具有绘制矩形的功能，所以势必要引入GUI库。对于C++来说就需要连接GUI的代码，这会浪费编译、链接以及消耗部分的内存。如果是Java程序，GUI的.class文件就必须被部署到目标平台。
如果GraphicalApplication的改变导致Rectangle也发生了变化，那么，这个变化会迫使我们重新构建、测试以及部署ComputationalGeometryApplication。

一个较好的设计是把这两个职责分离到如下两个不同的类中。实现解耦。

Screen Shot 2018-02-23 at 2.56.01 PM.png

可以看到，计算矩形面积的应用，只需要调用Geometric Rectangle来计算，这时候就不需要用到GUI库了。

职责被定义为"变化的原因"。如果有多个导致类变化的原因，那么这个类就具有多于一个的职责。

很多时候，我们很难去区分到底是否具有多个职责，是否有多个原因引起了累的变化。下面通过一个modem的类，来说明什么情况下会区分出职责。

考虑如下的代码：

interface Modem {
    public void dial(String pno);
    public void hanup();
    public void send(char c);
    public void recv();
}

可以看出这个类中包含了两个部分，一个是连接处理，一个是数据通信。

那一定要进行拆分么？

其实不一定，是否需要拆分取决于变化。