设计原则（三）单一职责原则

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
模式优点：
1、功能清晰，增强可读性
2、可扩展性，修改功能不会影响其它功能
3、降低各个功能之间的耦合
应用场景：
类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决办法：
遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

举个列子：

image.png

图中的接口ICar，即负责color,brand等属性的读取，又负责stop,start等动作行为。
即将车子的属性和行为耦合到一个接口当中，这就属于违反了单一职责原则。
那我们应该如何设计呢？
为了解决这个问题，应当使用单一职责原则，将车子接口中的业务对象（属性）和业务逻辑（行为）解耦，分成两个接口，如下：
修改后的设计如下：

image.png