[设计模式-1]23种GOF设计模式及7大原则概述

参考资料：

1. 自学大学B站免费教程，就不放链接了

2. 菜鸟教程-设计模式

3. 书籍-大话设计模式

4. 博客-设计模式总结

5. 博客-23 种设计模式详解（全23种）

6. 博客-史上最全设计模式导学目录（完整版）

7. 博客-五万字详解“GoF”的23种设计模式

1. 设计模式概念

1.1 GOF的含义

在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 的书，该书首次提到了软件开发中设计模式的概念。

四位作者合称 GOF（四人帮，全拼 Gang of Four）。他们所提出的设计模式主要是基于以下的面向对象设计原则。
对接口编程而不是对实现编程。
优先使用对象组合而不是继承。

由此这四个人写的这本书中提到的设计模式被称为GOF设计模式，共23种

1.2 设计模式定义

设计模式（Design pattern）：是软件开发经验的总结，是软件设计中常见问题的典型解决方案。每个模式都像一个蓝图，您可以自定义以解决代码中的特定设计问题。它不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。

1.3 设计模式分类

设计模式共分为 3 类模式, 分别为：创建型模式，结构型模式，行为型模式。

• 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式；
• 结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式；
• 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

实际上，设计模式要干的事情就是解耦。
创建型模式是将创建和使用代码解耦，结构型模式是将不同功能代码解耦，行为型模式是将不同的行为代码解耦，
其中又分为：

• 接口适配：适配器、外观、桥接模式
• 行为扩展：装饰模式
• 性能与对象访问：代理、享元模式
• 抽象集合：组合模式
• 算法封装：模板方法、策略、命令模式
• 对象去耦：中介、观察者模式
• 抽象集合：迭代器模式
• 行为扩展：访问者、责任链模式
• 对象状态：状态模式

图1（简单方便看）：

图2（有图标好理解，但少一种模式）：

图3（详细一点）：

图4（描述设计模式之间的关系）：

图5、图6（UML图）：

1.4 设计模式特性（优点）：低耦合、高内聚、维护、扩展、重用、灵活、可读、可靠

编写软件过程中，程序员面临着来自耦合性、内聚性、可维护性、可扩展性、重
用性、灵活性等多方面的挑战，设计模式是为了让程序(软件)具有一下特性：

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

另一种描述，设计模式的优点：

1. 提供了一种共享的设计词汇和概念，使开发人员能够更好地沟通和理解彼此的设计意图。
2. 提供了经过验证的解决方案，可以提高软件的可维护性、可复用性和灵活性。
3. 促进了代码的重用，避免了重复的设计和实现。
4. 通过遵循设计模式，可以减少系统中的错误和问题，提高代码质量。

2. 设计模式七大原则

2.1 开闭原则

开闭原则（Open Closed Principle，OCP）：软件实体应当对扩展开放，对修改关闭。

实现方法： 通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。

(另外描述) 开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

2.2 里氏替换原则

里氏替换原则（Liskov Substitution Principle，LSP）：继承必须确保超类所拥有的性质在子类中仍然成立。

里氏替换原则是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

对里氏替换原则的定义可以总结如下 4 点：

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法；
• 子类中可以增加自己特有的方法；
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松；
• 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等。

(另外描述) 里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

2.3 依赖倒置原则

依赖倒置原则（Dependence Inversion Principle，DIP）有 2条 原则：

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象；
• 抽象不应该依赖细节，细节应该依赖抽象。

核心思想是：要面向接口编程，不要面向实现编程, 降低类间的耦合性。
依赖倒置原则的主要作用如下:

• 依赖倒置原则可以降低类间的耦合性；
• 依赖倒置原则可以提高系统的稳定性；
• 依赖倒置原则可以减少并行开发引起的风险；
• 依赖倒置原则可以提高代码的可读性和可维护性。

依赖倒置原则的实现方法:

• 每个类尽量提供接口或抽象类，或者两者都具备；
• 变量的声明类型尽量是接口或者是抽象类；
• 任何类都不应该从具体类派生；
• 使用继承时尽量遵循里氏替换原则。

(另外描述) 这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

依赖倒转原则(Dependence Inversion Principle)是指：

1. 高层模块不应该依赖低层模块，二者都应该依赖其抽象
2. 抽象不应该依赖细节，细节应该依赖抽象
3. 依赖倒转(倒置)的中心思想是面向接口编程
4. 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的
   多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象
   指的是接口或抽象类，细节就是具体的实现类
5. 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的
   任务交给他们的实现类去完成

依赖倒转原则的注意事项和细节

1. 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好.
2. 变量的声明类型尽量是抽象类或接口, 这样我们的变量引用和实际对象间，就存在
   一个缓冲层，利于程序扩展和优化
3. 继承时遵循里氏替换原则

个人碎语：依赖倒转原则或者叫依赖倒置原则，本质上就是多使用接口编程，接口指定规范，具体实现才利用实现类，
使用时不是平常的依赖实现，而是依赖接口，将依赖从实现倒转为接口

2.4 单一职责原则（六大原则时不存在这一个）

单一职责原则（Single Responsibility Principle，SRP）单一功能原则：规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。

个人碎语：所谓单一职责，就是事情拆分尽量小，自己的事情自己做，不仅指类，也指方法、模块等。
比如一个大的需求单元可以一个模块，一个小的需求单元可以一个包，一个页面可以一个类，一个增删改查一个方法，
做到互不干扰，使代码被污染的可能型降低，互不影响，自然提高了可靠性。
方法方面更要小灵快，尽量拆小，这样好复用，多用重载，这样既做到了方法复用，又做到了不同场景不同方法。
简单来说方法的书写要做到小步快跑，方法小，灵活，更容易组合，更容易被复用，自然就可以写得更快了。

2.5 接口隔离原则

接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。

接口隔离原则定义：客户端不应该被迫依赖于它不使用的方法，一个类对另一个类的依赖应该建立在最小的接口上。

接口隔离原则的实现方法，在具体应用接口隔离原则时，应该根据以下几个规则来衡量：

• 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑；
• 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法；
• 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同，要深入了解业务逻辑；
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

(另外描述) 这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

个人碎语：通俗来讲就是，类A需要有三个方法，类B需要有三个方法，若它们都使用同一个接口C，那么C就需要有6个方法，且A、B都各自实现了三个不需要的方法，这种时候需要把接口C拆分成两个接口C1、C2，使接口尽量小，做到接口隔离原则，而不是更大更臃肿混在一起。

2.6 迪米特法则

迪米特法则（Law of Demeter，LoD）又叫作最少知识原则，只与你的直接朋友交谈，不跟“陌生人”说话。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

在运用迪米特法则时要注意以下 6 点:

• 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标；
• 在类的结构设计上，尽量降低类成员的访问权限；
• 在类的设计上，优先考虑将一个类设置成不变类；
• 在对其他类的引用上，将引用其他对象的次数降到最低；
• 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）；
• 谨慎使用序列化（Serializable）功能。

(另外描述) 最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

2.7 合成复用原则

合成复用原则（Composite Reuse Principle，CRP）又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范

(另外描述) 合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。