C++设计模式整理001-原则和分类

目录

1. 六大原则

1.1 单一职责原则

1.2 开放封闭原则

1.3 依赖倒置原则（Dependence Inversion Principle）

1.4 里式转换原则（Liskov Substitution Principle）

1.5 接口隔离原则（Interface Segregation Principle）

1.6 迪米特原则（Demeter Principle）

1.7 合成复用原创（Composite Reuse Principle）

2. 设计模式分类

2.1 创建型模式

2.2 结构型模式

2.3 行为型模式

---

1. 六大原则

 

1.1 单一职责原则

        单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。即，一个类值负责一项职责（功能）。

        简单点说：一个类只负责一件具体的事情，一个方法只完成一个特定的功能。当你发现一方法完成了两件事情的时候，就需要适当的重构成两个方法，类也是一样的。

        例如，每个颜色的水彩笔都有自己“单一的职责/用途”。

1.2 开放封闭原则

        开放封闭原则：对扩展开放，对修改关闭。

        在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。

        概括起来就是：为了使程序的扩展性好，易于维护和升级。

        比如：笔记本电脑，整个笔记本电脑是封闭的，只有人员可以去修改维护；笔记本电脑提供了N个USB插口，可供我们扩展。即对扩展开发，对修改关闭。

1.3 依赖倒置原则（Dependence Inversion Principle）

        依赖倒置原则：面向接口编程，依赖于抽象而不依赖于具体实现。

        写代码时用到具体类时，不于具体类交互，而与具体类的上层接口交互。（或者说，高层模块不应该依赖于底层模块，两个模块都应该依赖于抽象（抽象类 /接口））。

        例如：

                上网时，国外用Whatsapp，国内用QQ或微信。

                这时候，应该有个抽象类/接口，提供一个聊天方法。

                国外实现这个抽象聊天方法，用Whatsapp。国内实现这个抽象聊天方法，用QQ或微信。

1.4 里式转换原则（Liskov Substitution Principle）

        里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。

        里氏代换原则：任何基类可以出现的地方，子类一定可以出现。

        LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。

        里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

        里式替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。

                1. 一个软件实体如果使用的是一个父类的话，那么一定适用于其子类。而且它察觉不出父类对象和子类对象的区别。

                2. 在软件里面，把父类都替换成它的子类，软件的行为没有变化；简单点说，子类型必须能够替换掉它们的父类型。

        比如说:Unity 引擎是一个父类,Unity4.x，Unity5.x，Unity2017.x 都是这个父类下的子类。本身具备父类的功能，同时又都有自己的新功能。

1.5 接口隔离原则（Interface Segregation Principle）

        接口隔离原则：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。

                1. 客户端不应该依赖于它不需要的接口（即接口中不存在子类用不到却必须实现的方法）。

                2. 一个类对另一个类的依赖应该建立在最小的接口上。

        比如：

        公司有很多部门，开发部、财务部、销售部等等。

        如果把员工需要做的事，集合定义在一个接口里面，例如接口A里面提供接口：工资计算，客户开发，客户维护，软件开发，软件维护等等。就会出现问题，比如财务部的员工，也需要实现：客户开发，客户维护等等接口，但这些事情是不需要财务部员工去做的。

        所以，需要对接口进行“功能隔离”。例如，财务部员工接口有工资计算、财务管理等，开发部的员工接口有软件开发、软件维护等…。

        这样对接口功能隔离后，细分了不能部门的职责功能接口，不管是现有的员工，还是以后新加入的员工，只需要实现自己部门对应的接口即可。

1.6 迪米特原则（Demeter Principle）

        迪米特原则，也叫最少知道原则。即，一个类对自己依赖的类知道的越少越好。也就是说，无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当依赖的类变化时，才能最小的影响该类。

        最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。

                1. 如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另外一个类的某一个方法的话，可以通过第三者转发这个调用。

                2. 一个对象应当对其他对象有尽可能少的了解。

                3. 迪米特原则主要是强调了类与类之间的松耦合。类与类之间的耦合度越低，越有利于代码的复用，一个处于低耦合的类被修改了，不会对有关系的类造成影响。

        比如说:很多公司的董事长都会有自己的助理（秘书），负责帮自己处理公司的零散事情。

        比如说：公司需要开会，如果没有助理，那么董事长需要亲自去通知所有的员工；但是如果有助理，只需要把开会这件事告诉助理，然后董事长就不需要管了，助理会去通知所有的员工。

        在董事长和公司员工之间，多出来了一个助理，就可以降低董事长和公司员工之间的耦合度，这样可以提高董事长的时间价值和效率。

        没有助理：董事长需要面对 N 个员工，1 对 N 的关系；有了助理：董事长只需要面对助理 1 人，1 对 1 的关系；然后由助理去 1 对 N。

1.7 合成复用原创（Composite Reuse Principle）

        原则是尽量首先使用合成/聚合的方式，而不是使用继承。

2. 设计模式分类

2.1 创建型模式

        共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

2.2 结构型模式

        共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

2.3 行为型模式

        共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。