设计模式简介

什么是设计模式

软件设计模式（Software Design Pattern），俗称设计模式，设计模式是一套被反复使用的、多数人知晓的、经过
分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方
案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使
用。使用设计模式的目的是为了代码重用、让代码更容易被他人理解、保证代码可靠性。

设计模式使用场景

• 在程序软件架构设计上会使用到设计模式
• 在软件架构设计上会使用到设计模式

设计模式的目的：

• 提高代码的可重用性
• 提高代码的可读性
• 保障代码的可靠性

设计原则

优良的系统设计具备特点：

1. 可扩展性(Extensibility)
2. 灵活性(Flexibility)
3. .组件化可插拔式(Pluggability)
   面向对象编程常用的设计原则包括7个，这些原则并不是孤立存在的，它们相互依赖，相互补充。

单一职责原则

定义： 一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。

解说： 一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性越小，而且如果一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。

类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来体现。

单一职责原则是实现高内聚、低耦合的指导方针，在很多代码重构方法中都能找到它的存在，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

实例： 以登录实现为例：
原始设计方案：

开闭原则

定义： 一个软件实体应当对扩展开放，对修改关闭。也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为。

解说： 开闭原则还可以通过一个更加具体的“对可变性封装原则”来描述，对可变性封装原则(EVP)要求找到系统的可变 因素并将其封装起来。

如果一个软件设计符合开闭原则，那么可以非常方便地对系统进行扩展，而且在扩展时无须修改现有代码，使得软件系统在拥有适应性和灵活性的同时具备较好的稳定性和延续性。为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。

实例： 我们拿 表功能来说， BarChart和 PieChart为不同的 表功能，此时在 ChartDisplay中使用 表功能， 可以直接new对应的功能，但如果增加新的 表功能，在 ChartDisplay中使用，就需要改代码了，这就违背了开闭原则。

原始设计方案：

里氏代换原则

定义： 所有引用基类（父类）的地方必须能透明地使用其子类的对象。

解说： 里氏代换原则可以通俗表述为：在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象。

里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用 子类对象来替换父类对象。

使用里氏代换原则需要注意：
(1)子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。根据里氏代 换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。
(2) 我们在运用里氏代换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现 父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，我们可以很方便地 扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。
(3) Java语言中，在编译阶段，Java编译器会检查一个程序是否符合里氏代换原则，这是一个 与实现无关的、纯语法意义上的检查，但Java编译器的检查是有局限的。

**实例：**我们以给客户发消息为例，给VIP客户(VipCustomer)和普通客户(CommonCustomer)发消息,在 SendMessage 中分别定义给普通会员和VIP发消息，如果以后有新的客户分类，不仅要添加客户分类，还要修改SendMessage ，违背了开闭原则。

原始设计方案：

依赖倒转原则

定义： 抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

注意点： **依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层 、类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据 类型的转换等，而不要用具体类来做这些事情。**为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。

在引入抽象层后，系统将具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统的功能，满足开闭原则的要求。

在实现依赖倒转原则时，我们需要针对抽象层编程，而将具体类的对象通过依赖注入 (DependencyInjection, DI)的方式注入到其他对象中，依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有三种，分别是：构造注入，设值注入（Setter注入）和接口注入。构造注入是指通过构造函数来传入具体类的对象， 设值注入是指通过Setter方法来传入具体类的对象，而接口注入是指通过在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型的对象，由子类对象来覆盖父类对象。

总结：

1. 针对接口编程
2. 在接口或抽象类中定义方法、声明变量
3. 类只实现接口或抽象类中的方法，不要定义多余的方法
4. 给抽象对象或接口注入依赖对象时，采用依赖注入方式

实例：
我们可以把之前的开闭原则案例修改一下，利用Spring框架进行修改，可读性更强，同时遵循了开闭原则、里氏代换原则和依赖倒转原则，如下图：

设计模式分类

GOF中共提到了23种设计模式不是孤立存在的，很多模式之间存在一定的关联关系，在大的系统开发中常常同时使
用多种设计模式。这23种设计模式根据功能作用来划分，可以划分为3类：

1. 创建型模式： 用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”，单例、原型、工厂方法、抽象工厂、建造者5种设计模式属于创建型模式。
2. 结构型模式： 用于描述如何将类或对象按某种布局组成更大的结构，代理、适配器、桥接、装饰、外观、享元、组合7种设计模式属于结构型模式。
3. 行为型模式： 用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器11种设计模式属于行为型模式。

GOF的23种设计模式：

1. 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
2. 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
3. 工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
4. 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
5. 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该 复杂对象。
6. 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、 增强或修改该对象的一些特性。
7. 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的 那些类能一起工作。
8. 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽 象和实现这两个可变维度的耦合度。
9. 装饰（Decorator）模式：动态的给对象增加一些职责，即增加其额外的功能。
10. 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
11. 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
12. 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
13. 模板方法（TemplateMethod）模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以 不改变该算法结构的情况下重定义该算法的某些特定步骤。
14. 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响 使用算法的客户。
15. 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
16. 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通 过这种方式去除对象之间的耦合。
17. 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
18. 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象， 从而影响其他对象的行为。
19. 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有 对象之间不必相互了解。
20. 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
21. 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多 个访问者对象访问。
22. 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
23. 解释器（Interpreter）模式：提供如何定义语言的放法，以及对语言句子的解释方法，即解释器。