单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，这里的职责是指类变化的原因。
单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
以上是单一职责的基本概念，可以看到两句话中两次提到了"变化的原因"。
变化是软件生命周期中持续存在的过程，也可以说变化促进了软件的发展，如果软件不再发生变化，那么这个软件就停止了发展。
从这个角度来说，变化是积极有益的。
但是变化也消极有害的一面，这主要体现在变化的过程中对软件中一些已有的、无需变化的部分造成干扰，从而对软件产生结构性损害，造成软件无法正常工作。
如果软件的所有部分都发生了变化，那使用设计模式是难以支撑的，这时需要考虑的不是“重构”，而是“重写”。
如果软件的所有部分都不发生变化，那使用设计模式是没有意义的，这时需要考虑的是“效率”，而不是“扩展”。
麻烦的是软件的某些部分变化而某些部分没有变化，面向对象设计模式就是为了解决此项问题而提出的。
回到本文所讲的主题——单一职责原则，这项原则强调的是“业务逻辑隔离”。
按照面向对象的思想，把每种业务逻辑当作一个“人”的话，那么这些“人”就是有传染病的“病人”。而我们的软件就是一所“传染病医院”。单一职责，就相当于对不同的传染病类型的病人，隔离治疗——划分在不同的病区和病房。而防止病人之间的相互传染。
但业务逻辑又与人不同，它是一种概念——无形的概念。
所以，想要对业务逻辑进行合理的隔离，就需要将业务逻辑之间的边界“尽可能清晰”的分隔开，但是很难做到“完全清晰”的分隔。
分隔的粒度太细，那就会导致零散，而难以管理；分割的粒度太粗，又会造成变化与不变化的耦合。
因此只能尽量寻找一个平衡点，使得业务逻辑的划分粒度与业务逻辑的变化程度达到一种动态的平衡，
在每次业务逻辑发生变化的时候，当前的粒度的划分能够把变化产生的风险维持在可控范围内。
因此，想要通过使用此项原则来构建稳定可靠的软件，除了要有较强的分析设计能力和相关重构经验这些技术层面的能力，还需要对业务的变化有尽可能准确的判断，而软件的业务又与市场的变化息息相关——这些非技术层面的能力，对于设计出优秀的软件产品也是至关重要的。
合理的运用设计模式对软件进行设计，应该是基于对市场的变化趋势和业务的发展方向的“嗅觉”，而不是为了运用模式而用模式，为了重构而重构的“秀技”。
