设计模式简介

什么是设计模式

软件设计模式（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框架进行修改，可读性更强，同时遵循了开闭原则、里氏代换原则和依赖倒转原则，如下图：

接口隔离原则

定义： 使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

讲解： 接口仅仅提供客户端 需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口， 而不要提供大的总接口。在面向对象编程语言中，实现一个接口就需要实现该接口中定义的 所有方法，因此大的总接口使用起来不一定很方便，为了使接口的职责单一，需要将大接口 中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来都较为方便， 并都承担某一单一角色。接口应该尽量细化，同时接口中的方法应该尽量少，每个接口中只 包含一个客户端（如子模块或业务逻辑类）所需的方法即可，这种机制也称为“定制服务”，即 为不同的客户端提供宽窄不同的接口。

总结： 需要用到哪些方法，接口中就只提供哪些方法，用不到的方法，接口中不提供。

注意： 我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即可，不应该 强 迫客户依赖于那些它们不用的方法。

实例： 下图展示了一个拥有多个客户类的系统，在系统中定义了一个巨大的接口DataRead来服务所有的客户类。
原始设计方案：

基于接口隔离原则进行重构:

合成复用原则

定义： 尽量使用对象组合（接口注入模式），而不是继承来达到复用的目的。

讲解： 合成复用原则就是在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用功能的目的。简言之：复用时要尽量使用组合/聚合关系（关联关系），少用继承。

在面向对象设计中，可以通过两种方法在不同的环境中复用已有的设计和实现，即通过组合/ 聚合关系或通过继承，但首先应该考虑使用组合/聚合，组合/聚合可以使系统更加灵活，降低 类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少；其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。

通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白 箱”复用，如果基类发生改变，那么子类的实现也不得不发生改变；

由于组合或聚合关系可以将已有的对象（也可称为成员对象）纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现 细节对于新对象不可见。

总结： 复用的方式： ①组合/聚合关系实现复用 ②继承实现复用
继承复用问题：会破坏系统的封装性，会把基类实现暴露给子类。
组合/聚合复用：已有对象的功能细节，对组合而成的新对象是不可见的，封装性教好。

实例： 图书管理系统中，如果数据在MySQL中，我们需要创建一个链接MySQL的工具类 MySQLUtil ,Dao只需要继承该工具类即可操作数据库，如果把数据库换成Oracle，我们需要新建一个工具类 OracleUtil ，Dao需要修改继承对象改OracleUtil ,这就违反了开闭原则。

原始设计方案：

基于合成复用原则进行重构:

我们把 OracleUtil作为 MySQLUtil的子类，BookDao中把 MySQLUtil作为一个属性组合进来，每次需要变更数据库链接的时候，只需要修改BookDao的依赖注入配置文件即可。这里符合里氏替换原则。

迪米特法则

定义： 一个软件实体应当尽可能少的与其他实体发生相互作用。

讲解： 如果一个系统符合迪米特法则，那么当其中某一个模块发生修改时，就会尽量少的影响其他模块，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。

迪米特法则要求我们在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。简言之，就是通过引 入一个合理的第三者来降低现有对象之间的耦合度。

作用： 降低系统的耦合度

实例： 我们在做增删改查的时候，如果直接用控制层调用Dao，业务处理的关系会比较乱，我们需要合理增加一个中
间对象(业务层)来解决个问题。

原始设计方案：

基于迪米特法则进行重构：

设计模式分类

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）模式：提供如何定义语言的放法，以及对语言句子的解释方法，即解释器。