单一职责原则

单一职责原则的定义是：

应该有且仅有一个原因引起类的变更。

我们来总结一下单一职责原则有什么好处：

• 类的复杂性降低，实现什么职责都有清晰明确的定义；
• 可读性提高，复杂性降低，那当然可读性提高了；
• 可维护性提高，可读性提高，那当然更容易维护了；
• 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

对于接口和类：

我们在设计接口的时候，一定要做到单一，但是对于实现类就需要多方面考虑了。生搬硬套单一职责原则会引起类的剧增，给维护带来非常多的麻烦，而且过分细分类的职责也会人为地增加系统的复杂性。本来一个类可以实现的行为硬要拆成两个类，然后再使用聚合或组合的方式耦合在一起，人为制造了系统的复杂性。所以原则是死的，人是活的，这句话很有道理。

问题难点：

单一职责原则最难划分的就是职责，一个职责一个接口，但问题是“职责” 没有一个量化的标准，而这个标准的颗粒度粗细决定，往往每个人的标准不统一，所以单一职责原则也就比较难以划分。是的，类的单一职责确实受非常多因素的制约，纯理论地来讲，这个原则是非常优秀的，但是现实有现实的难处，你必须去考虑项目工期、成本、人员技术水平、硬件情况、网络情况甚至有时候还要考虑政府政策、垄断协议等因素。

如果对接口、类、方法使用了单一职责原则，那么快乐的就不仅仅是你了，还有你的项目组成员，大家可以轻松而又愉快地进行开发；还有你的老板，减少了因为变更引起的工作量，减少了无谓的人员和资金消耗。

建议取舍：

“对于单一职责原则，我的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。”

大家多和热水~早点休息