S-O-L-I-D 原则 之 单一职责原则

同事给了发了一份文档，主了讲了S-O-L-I-D原则，有的是专题，有的是从某本书中拿出来的一节，全英文的，我觉得这些原则很重要，于是把自己半翻译半理解的写到这里，加深自己理解。

 

S- Single Responsibility Principle(SRP)单一职责原则  

引：只有佛自己有道破玄机的责任。

 

单一职责表现为“强聚集”(cohesion)，不应该有一个以上的原因修改一个类。

例如一个保龄球小游戏，可以用一个"Game"类处理两个单独的职责。一个是保持现在框架的轨迹，另一个是计算分数，但最后它被拆成了两个类。因为每个职责是类修改的一个基准线，当需求改变时，它通过改变类的职责表现出来。如果一个类有多于一个的职责，它将有多于一个的原因改变。当修改其中一个职责时有可能会影响到其它职责的实现，它会使设计变得脆弱。

在这里“职责”被定义为“导致改变的原因”，如果我们可以想到多于一个原因导致一个类的改变，那么这个类就多于一个职责。但这有时很难看清楚。我们习惯以组的形式思考职责。例如我们想到“Modem"的接口如下，大部分人会认为这些接口看起来是合理的。这四个函数声明确实属于一个调试解调器。

 

interface Modem

{

    public void dial(string pno);

    public void hangup();

    public void send(char c);

    public char recv();

}

 

但是，这里看到了两个职责。第一个是连接管理，第二个是数据通信。dial和hangup函数管理调试解调器的连接，而send和recv传输数据。这两个职责应该分开吗？答案是肯定的。这两组函数几乎没有共同之处，它们会因为不同的原因改变。因此，下面的设计也许会好些。它将两个职责拆分成两个接口，它至少使应用程序不再拥有两个职责。

 

 

但是还是把两个职责放到了单一的类ModemImplementation中，这不是想要的，但可能是必须的。这往往与硬件或操作系统的细节有关，强迫我们连接一些我们不想要的职责。然而，通过拆分接口，至少相对于其它应用我们将职责分开了。我们也可以把这个类看成一个组合。

 

结论：SRP是最基本的原则之一，但也是最难使用的一个。我们经常很自然地把职责连接在一起。发现和拆分这些职责是软件设计要做的重要工作之一，其它原则也会跟它相关。