面向对象设计模式原则01 单一职责原则(SRP)

单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，这里的职责是指类变化的缘由。

单一职责原则规定一个类应该有且仅有一个引发它变化的缘由，不然类应该被拆分。

以上是单一职责的基本概念，能够看到两句话中两次提到了"变化的缘由"。

变化是软件生命周期中持续存在的过程，也能够说变化促进了软件的发展，若是软件再也不发生变化，那么这个软件就中止了发展。

从这个角度来讲，变化是积极有益的。

可是变化也消极有害的一面，这主要体如今变化的过程当中对软件中一些已有的、无需变化的部分形成干扰，从而对软件产生结构性损害，形成软件没法正常工做。

若是软件的全部部分都发生了变化，那使用设计模式是难以支撑的，这时须要考虑的不是“重构”，而是“重写”。

若是软件的全部部分都不发生变化，那使用设计模式是没有意义的，这时须要考虑的是“效率”，而不是“扩展”。

麻烦的是软件的某些部分变化而某些部分没有变化，面向对象设计模式就是为了解决此项问题而提出的。

回到本文所讲的主题——单一职责原则，这项原则强调的是“业务逻辑隔离”。

按照面向对象的思想，把每种业务逻辑看成一个“人”的话，那么这些“人”就是有传染病的“病人”。而咱们的软件就是一所“传染病医院”。单一职责，就至关于对不一样的传染病类型的病人，隔离治疗——划分在不一样的病区和病房。而防止病人之间的相互传染。

但业务逻辑又与人不一样，它是一种概念——无形的概念。

因此，想要对业务逻辑进行合理的隔离，就须要将业务逻辑之间的边界“尽量清晰”的分隔开，可是很难作到“彻底清晰”的分隔。

分隔的粒度太细，那就会致使零散，而难以管理；分割的粒度太粗，又会形成变化与不变化的耦合。

所以只能尽可能寻找一个平衡点，使得业务逻辑的划分粒度与业务逻辑的变化程度达到一种动态的平衡，

在每次业务逻辑发生变化的时候，当前的粒度的划分可以把变化产生的风险维持在可控范围内。

所以，想要经过使用此项原则来构建稳定可靠的软件，除了要有较强的分析设计能力和相关重构经验这些技术层面的能力，还须要对业务的变化有尽量准确的判断，而软件的业务又与市场的变化息息相关——这些非技术层面的能力，对于设计出优秀的软件产品也是相当重要的。

合理的运用设计模式对软件进行设计，应该是基于对市场的变化趋势和业务的发展方向的“嗅觉”，而不是为了运用模式而用模式，为了重构而重构的“秀技”。