单一职责:

就一个类而言，应该仅有一个引起它变化的原因。对于一个接口，应该只有一个职责。 每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。通常超长的函数，大都是因为实现了多个功能。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。

原理

如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。

问题由来

之所以会出现单一职责原则就是因为在软件设计时会出现以下类似场景：

T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。也就是说职责P1和P2被耦合在了一起。

产生原因

没有任何的程序设计人员不清楚应该写出高内聚低耦合的程序，但是很多耦合常常发生在不经意之间，其原因就是：

职责扩散：因为某种原因，某一职责被分化为颗粒度更细的多个职责了。

解决办法

遵守单一职责原则，将不同的职责封装到不同的类或模块中。

好处

·        类的复杂性降低，实现什么职责都有清晰明确的定义；

·        可读性提高，复杂性降低，那当然可读性提高了；

·        可维护性提高，那当然了，可读性提高，那当然更容易维护了；

·        变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大帮助。

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

最后，原则就是原则，要在开发过程中进行权衡遵守这一规则的利弊。很多时候，需要学院派和实用派相结合的方式去利用原则，才能达到很好的效果。要多锻炼怎么去用原则，直到他融入血液，一使用，就自然而然的应用，从心所欲，手到擒来。

This browser does not support music or audio playback. Please play it in WeChat or another browser.