设计模式——单一职责原则

基本介绍：

对类来说，即一个类应该只负责一项职责，如类A负责两个不同的职责：职责1，职责2

当职责1需求变更而改变A，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2

有如下代码

该run方法中，违反了单一职责原则

解决方案：

根据交通工具运行的方式不同，分解成不同的类即可

遵守了单一职责原则

但是这样做的改动很大，即将类分解，同时修改客户端

改进：直接修改Vehicle类，改动的代码会比较少

这种修改方法没有对原来的类做大的修改，只是增加方法

这里虽然没有在类这个级别上遵守单一职责原则，但是在方法级别上，仍然是遵守单一职责

注意事项和细节

1. 降低类的复杂度，一个类只负责一项职责
2. 提高类的可读性，可维护性
3. 降低变更引起的风险
4. 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

总结

设计模式的目的

编写软件过程中，我们面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序具有更好

1. 代码重用性（即：相同功能的代码，不用多次编写）
2. 可读性（即：编程规范性，便于其他程序员的阅读和理解）
3. 可扩展性（即：当需要增加新的功能时，非常的方便，称为可维护）
4. 可靠性（即：当我们增加新的功能后，对原来的功能没有影响）
5. 使程序呈现高内聚，低耦合的特性