设计模式基础三原则

单一职责原则(SRP)

概述

• 一个类应该有一个引起它变化的原因
• 变化的方向隐含着类的责任

对一个类而言，它的职责应该是单一的。 如果它承担的职责过多，就等于把这些职责耦合在一起了，当它其中的一个职责变化时可能会对这个类的其他职责产生一些不好的影响，从而产生一些意想不到的BUG。

软件设计真正要做的事情就是，根据需求发现职责，并把这些职责进行分离，添加新的类，给当前类减负，越是这样项目才越容易维护。

开放封闭原则(OCP)

概述

• 对扩展开放，对修改封闭
• 类模块应该是可扩展的，但是不可修改

其实是软件实体（类、模块、函数等）可以扩展，但是不可以修改。
具体实现就是通过 多态 的应用。在一些可能变化的地方封装使用抽象类，创建子类并重写父类的抽象函数，从而达到扩展而非修改。

• 此处的抽象类，其实并不等价与 C++ 中完全意义上是抽象类（需要有纯虚函数），这里所说的抽象类只需要包含虚函数（纯虚函或非纯虚函数）能够实现多态即可。

举例

对于电商打折，可以创建一个A类实现打折算法，但由于不同时节其具体打折策略不同，如果不采用开放封闭原则，那么每次打折策略变化时都药修改A类，这样会造成巨大的工作量;如果创建一个抽象类并使A类继承它，当打折策略变化的时候只需要创建新的子类并重写抽象类的打折策略虚函数就可以根据抽象类的父类指针引用其子类的实例对象达到目的。

依赖倒置原则(DIP)

概述

• 高层模块（稳定）不应依赖低层模块（变化），二者都应依赖与抽象
• 抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象

举例

某项目组接了一个新项目，低层使用的是 MySql 的数据库接口，高层基于这套接口对数据库表进行了添删查改，实现了对业务层数据的处理。而后由于某些原因，要存储到数据库的数据量暴增，所以更换了 Oracle 数据库，由于低层的数据库接口变了，高层代码的数据库操作部分是直接调用了低层的接口，因此也需要进行对应的修改，无法实现对高层代码的直接复用。

基于依赖倒转原则将例子中项目的结构换成这种模式之后，低层模块发生变化，对应高层模块是没有任何影响的，这样程序员的工作量降低了，代码也更容易维护（实际还是依赖倒转原则就是对多态的典型应用）。

总结

• 抽象类中提供的接口是固定不变的
• 低层模块是抽象类的子类，继承了抽象类的接口，并且可以重写这些接口的行为
• 高层模块想要实现某些功能，调用的是抽象类中的函数接口，并且是通过抽象类的父类指针引用其子类的实例对象（用子类类型替换父类类型），这样就实现了多态