单一职责原则

单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。

?

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

?

软件设计时要发现职责并把那些职责相互分离。如何判断是否应该分离呢？如果你能够想到多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

?

例如：在电话类的设计中，接口包含三个方法：拨号，通话和挂电话。但是这个接口包含了两个职责，拨号和挂电话属于协议管理，通话属于数据传输。不符合单一职责原则。

可以将拨号和挂电话作为一个接口，通话作为一个接口，一个类实现了这两个接口，把两个职责融合在一个类中，对外公布的是接口，而不是实现类。

遵循单一职责原则的优点

• 降低了类的复杂度。一个类只负责一项职责比负责多想职责要简单得多。
• 提高了代码的可读性。一个类简单了，可读性自然就提高了。
• 提高了系统的可维护性。代码的可读性高了，并且修改一项职责对其他职责影响降低了，可维护性自然就提高了。
• 变更引起的风险变低了。单一职责最大的优点就是修改一个功能，对其他功能的影响显著降低。

?

本教程参考“大话设计模式”，作者：程杰。