浅谈设计原则SRP

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

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

有关类的职责分配问题，是面向对象设计中最重要的基本原则

“A critical, fundamental ability in OOA/D is to skillfully assign responsibility to software components.”
 【Craig Larman】

SRP本质

SRP体现了内聚性（Cohesion）

内聚性：一个模块的组成元素之间的功能相关性

类的职责定义为“变化的原因”，每个职责都是变化的一个轴线；

当需求变化时，该变化会反映为类的职责的变化

如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个

【承担的职责越多，变化的原因就越多】

违反SRP的案例

Rectangle类可能会因为两方面的原因而变化：计算几何方面的原因和用户界面设计方面的原因。

其中只一发生变化之后，必须修改Rectangle类，而这种修改则可能导致另一个应用程序出错

解决方案

增加新的类，使得每个类仅有一个职责

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。

问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

说到单一职责原则，很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。

【ps:职责的划分是笼统的，有时候我们不一定必须遵守，但是的确划分职责会给我我们带来方便】

遵循单一职责原的优点有：

l 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；

l 提高类的可读性，提高系统的可维护性；

l 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都需要遵循这一重要原则。

【很多设计模式都会遵守这个原则，比如迭代器模式，遍历职责不应该与业务逻辑放在一个类中】