1：PDF上传链接

【免费】敏捷软件开发(原则模式与实践)资源-CSDN文库

        这条原则曾经在Tom DeMaro和Meilir Page-Jones的著作中描述过，并称之为内聚性。他们把内聚性定义为：一个模块的组成元素之间的功能相关性。

8.1 单一职责原则（SRP）

        就一个类而言，应该仅有一个引起它变化的原因。

        为何要把这两个职责分离导单独的类中呢？因为每一个职责都是变化的一个轴线。当需求变化时，该变化会反应为类的职责的变化，如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。

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

 8.1.1 什么是职责

        在SRP中，我们把职责定义为“变化的原因”，如果你能够想到多于一个的动机去改变一个了，那么这个类就具有多于一个的职责。有时，我们很难注意到这一点。我们习惯于以组的形式去考虑职责。

图8.1.1.1

 8.1.2 分离耦合的职责

        值得注意的，在图8.3中，我把两个职责都耦合进了Modemlmplementation类中，这个不是所希望的，但是或许是必要的。常常会有一些和硬件或者操作系统的细节有关的原因，迫使我们把不愿耦合在一起的东西耦合在了一起，然而，对于应用的其余部分来说，通过分离他们的接口我们已经解耦了概念。

        我们可以把Modemlmplementation类看作是一个杂凑物，或者一个瑕疵。然而，请注意所有的依赖关系都和它无关。谁也不需要依赖它。除了main外，谁也不需要知道它的存在。

 8.1.3 持久化

8.2 结论

        SRP是所有原则中最简单的之一，也是最难正确运用的之一。我们会自然地把职责结合在一起。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。事实上，我们将要论述的其他原则都会以这样或那样的方式回到这个问题上。