基本介绍：
对类来说，即一个类应该只负责一项职责，如类A负责两个不同的职责：职责1，职责2
当职责1需求变更而改变A，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2
有如下代码
该run方法中，违反了单一职责原则
解决方案：
根据交通工具运行的方式不同，分解成不同的类即可
遵守了单一职责原则
但是这样做的改动很大，即将类分解，同时修改客户端
改进：直接修改Vehicle类，改动的代码会比较少
这种修改方法没有对原来的类做大的修改，只是增加方法
这里虽然没有在类这个级别上遵守单一职责原则，但是在方法级别上，仍然是遵守单一职责
注意事项和细节
- 降低类的复杂度，一个类只负责一项职责
- 提高类的可读性，可维护性
- 降低变更引起的风险
- 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则
总结
设计模式的目的
编写软件过程中，我们面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序具有更好
- 代码重用性（即：相同功能的代码，不用多次编写）
- 可读性（即：编程规范性，便于其他程序员的阅读和理解）
- 可扩展性（即：当需要增加新的功能时，非常的方便，称为可维护）
- 可靠性（即：当我们增加新的功能后，对原来的功能没有影响）
- 使程序呈现高内聚，低耦合的特性