设计模式三原则

1.1单一职责原则

C++ 面向对象三大特性之一的封装指的就是将单一事物抽象出来组合成一个类，所以我们在设计类的时候每个类中处理的是单一事物而不是某些事物的集合。

设计模式中所谓的单一职责原则，就是对一个类而言，应该仅有一个引起它变化的原因，其实就是将这个类所承担的职责单一化，如果一个类承担的职责过多，就等于把这些职责耦合到了一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致设计变得脆弱，当变化发生时，设计会遭受到意想不到的破坏。

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

1.2开放封闭原则

开放 – 封闭原则说的是软件实体（类、模块、函数等）可以扩展，但是不可以修改。也就是说对于扩展是开放的，对于修改是封闭的。

该原则是程序设计的一种理想模式，在很多情况下无法做到完全的封闭。但是作为设计人员，应该能够对自己设计的模块在哪些位置产生何种变化了然于胸，因此需要在这些位置创建抽象类来隔离以后发生的这些同类变化（其实就是对多态的应用，创建新的子类并重写父类虚函数，用以更新处理动作）。此处的抽象类，其实并不等价于 C++ 中完全意义上是抽象类（需要有纯虚函数），这里所说的抽象类只需要包含虚函数（纯虚函数或非纯虚函数）能够实现多态即可。

开放 – 封闭原则是面向对象设计的核心所在，这样可以给我们设计出的程序带来巨大的好处，使其可维护性、可扩展性、可复用性、灵活性更好。

1.3依赖倒转原则（对多态的典型应用）

关于依赖倒转原则，对应的是两条非常抽象的描述：

1.高层模块不应该依赖低层模块，两个都应该依赖抽象。

2.抽象不应该依赖细节，细节应该依赖抽象。

先用人话解释一下这两句话中的一些抽象概念：

高层模块：可以理解为上层应用，就是业务层的实现，编写的应用程序
低层模块：可以理解为底层接口，比如封装好的 API、动态库等
抽象：指的就是抽象类或者接口，在 C++ 中没有接口概念（Java里有），只有抽象类（在设计模式里的抽象类没有那么严格，可以为虚函数或纯虚函数），C++中定义接口的方法是在父类定义虚函数，在子类中重写虚函数。

举一个高层模块依赖低层模块的例子：

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

解决方法是高层和底层代码之间设计好抽象类和抽象类子类，写好调用MySQL的抽象子类，当底层换成Oracle数据库时，只需要增加调用Oracle的抽象子类，从而减少工作量。

通过上面的例子可以得知，当依赖的低层模块变了就会牵一发而动全身，如果这样设计项目架构，对于程序猿来说，其工作量无疑是很重的。如果要搞明白这个案例的解决方案以及抽象和细节之间的依赖关系，需要先了解另一个原则——里氏代换原则

里氏代换原则

里氏代换原则就是子类类型必须能够替换掉它们的父类类型。

关于这个原理的应用其实也很常见，比如在 Qt 中，所有窗口类型的类的构造函数都有一个 QWidget* 类型的参数（QWidget 类是所有窗口的基类），通过这个参数指定当前窗口的父对象。虽然参数是窗口类的基类类型，但是我们在给其指定实参的大多数时候，指定的都是子类的对象，其实也就是相当于使用子类类型替换掉了它们的父类类型。

上面在讲依赖倒转原则的时候说过，抽象不应该依赖细节，细节应该依赖抽象。也就意味着我们应该对细节进行封装，在 C++ 中就是将其放到一个抽象类中（C++ 中没有接口，不能像 Java 一样封装成接口），每个细节就相当于上面例子中的哺乳动物的一个特性，这样一来这个抽象的哺乳动物类就成了项目架构中高层和低层的桥梁，将二者整合到一起。