单一职责原则

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

?

单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。

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

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。其实要去判断是否应该分离出类来，也不难，那就是如果你能够想到多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

编程时，我们要在类的职责分离上多思考，做到单一职责，这样你的代码才是真正的易维护、易扩展、易复用、灵活多样。