第 1 章 内容介绍和授课方式

Java 设计模式内容介绍

先看几个经典的面试题

• 原型设计模式问题：

1. 有请使用 UML 类图画出原型模式核心角色
2. 原型设计模式的深拷贝和浅拷贝是什么，并写出深拷贝的两种方式的源码(重写 clone 方法实现深拷贝、使用序列化来实现深拷贝)
3. 在 Spring 框架中哪里使用到原型模式，并对源码进行分析

beans.xml

1. Spring 中原型 bean 的创建，就是原型模式的应用
2. 代码分析+Debug 源码

• 设计模式的七大原则: 要求：1) 七大设计原则核心思想 2) 能够以类图的说明设计原则 3) 在项目实际开发中，

你在哪里使用到了 ocp 原则

• 解释器设计模式

1. 介绍解释器设计模式是什么?
2. 画出解释器设计模式的 UML 类图,分析设计模式中的各个角色是什么?
3. 请说明 Spring 的框架中，哪里使用到了解释器设计模式，并做源码级别的分析
4. Spring 框架中 SpelExpressionParser 就使用到解释器模式
5. 代码分析+Debug 源码+模式角色分析说明

• 单例设计模式一共有几种实现方式？请分别用代码实现，并说明各个实现方式的优点和缺点? 单例设计模式一共有 8 种写法，后面我们会依次讲到

饿汉式 两种懒汉式 三种双重检查
静态内部类枚举

设计模式的重要性

1. 软件工程中，设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。这个术语是由埃里希·伽玛（Erich Gamma）等人在 1990 年代从建筑设计领域引入到计算机科学的
2. 大厦 VS 简易房
3. 拿实际工作经历来说, 当一个项目开发完后，如果客户提出增新功能，怎么办?。（可扩展性,使用设计模式，软件具有很好的扩展性）

1. 如果项目开发完后，原来程序员离职，你接手维护该项目怎么办? (维护性[可读性、规范性])
2. 目前程序员门槛越来越高，一线 IT 公司(大厂)，都会问你在实际项目中使用过什么设计模式，怎样使用的，解决了什么问题。
3. 设计模式在软件中哪里？面向对象(oo)=>功能模块[设计模式+算法(数据结构)]=>框架[使用到多种设计模式]=> 架构 [服务器集群]
4. 如果想成为合格软件工程师，那就花时间来研究下设计模式是非常必要的.

课程亮点和授课方式

1. 课程深入,非蜻蜓点水
2. 课程成体系，非星星点灯
3. 高效而愉快的学习 , 设计模式很有用，其实也很好玩，很像小时候搭积木, 怎样搭建更加稳定，坚固
4. 设计模式很重要，因为包含很多编程思想，还是有一定难度的，我们努力做到通俗易懂
5. 采用 应用场景->设计模式->剖析原理->分析实现步骤(图解)->代码实现-> 框架或项目源码分析(找到使用的地方) 的步骤讲解 [比如: 建造者模式 ]
6. 课程目标：让大家掌握本质 , 达能在工作中灵活运用解决实际问题和优化程序结构的目的.

第 2 章 设计模式七大原则

设计模式的目的

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

1. 代码重用性 (即：相同功能的代码，不用多次编写)

2. 可读性 (即：编程规范性, 便于其他程序员的阅读和理解)

3. 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护)

4. 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响)
5. 使程序呈现高内聚，低耦合的特性分享金句：
6. 设计模式包含了面向对象的精髓，“懂了设计模式，你就懂了面向对象分析和设计（OOA/D）的精要”
7. Scott Mayers 在其巨著《Effective C++》就曾经说过：C++老手和 C++新手的区别就是前者手背上有很多伤疤

设计模式七大原则

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础(即：设计模式为什么这样设计的依据)

• 设计模式常用的七大原则有:

1. 单一职责原则
2. 接口隔离原则
3. 依赖倒转(倒置)原则
4. 里氏替换原则
5. 开闭原则
6. 迪米特法则
7. 合成复用原则

单一职责原则

基本介绍

对类来说的，即一个类应该只负责一项职责。如类 A 负责两个不同职责：职责 1，职责 2。当职责 1 需求变更而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2

应用实例

以交通工具案例讲解看老师代码演示

3) 方案 3 [分析说明]

单一职责原则注意事项和细节

1. 降低类的复杂度，一个类只负责一项职责。
2. 提高类的可读性，可维护性
3. 降低变更引起的风险
4. 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

接口隔离原则(Interface Segregation Principle)

基本介绍

1. 客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

2. 先看一张图:

1. 类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C

来说不是最小接口，那么类 B 和类 D 必须去实现他们不需要的方法。

1. 按隔离原则应当这样处理：

将接口 Interface1 拆分为独立的几个接口(这里我们拆分成 3 个接口)，类 A 和类 C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则

应用实例

1. 类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，请编写代码完成此应用实例。
2. 看老师代码-没有使用接口隔离原则代码 | package com.atguigu.principle.segregation;
   
   public class Segregation1 {
   
   public static void main(String[] args) {
   // TODO Auto-generated method stub
   
   }
   
   }
   
   //接口
   interface Interface1 {
   void operation1(); void operation2(); | | —- |

应传统方法的问题和使用接口隔离原则改进

1. 类 A 通过接口 Interface1 依赖类 B，类 C 通过接口 Interface1 依赖类 D，如果接口 Interface1 对于类 A 和类 C

来说不是最小接口，那么类 B 和类 D 必须去实现他们不需要的方法

1. 将接口 Interface1 拆分为独立的几个接口，类 A 和类 C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
2. 接口 Interface1 中出现的方法，根据实际情况拆分为三个接口

1. 代码实现 | package com.atguigu.principle.segregation.improve;
   
   public class Segregation1 {
   
   public static void main(String[] args) {
   // TODO Auto-generated method stub
   // 使用一把
   A a = new A();
   a.depend1(new B()); // A 类通过接口去依赖 B 类
   a.depend2(new B());
   a.depend3(new B());
   
   C c = new C();
   
   c.depend1(new D()); // C 类通过接口去依赖(使用)D 类
   c.depend4(new D());
   c.depend5(new D()); | | —- |

依赖倒转原则

基本介绍

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

1. 高层模块不应该依赖低层模块，二者都应该依赖其抽象
2. 抽象不应该依赖细节，细节应该依赖抽象

3. 依赖倒转(倒置)的中心思想是面向接口编程

4. 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 java 中，抽象指的是接口或抽象类，细节就是具体的实现类

5. 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

   应用实例

请编程完成 Person 接收消息 的功能。

1. 实现方案 1 + 分析说明 | package com.atguigu.principle.inversion;
   
   public class DependecyInversion { | | —- |

1. 实现方案 2(依赖倒转) + 分析说明 | package com.atguigu.principle.inversion.improve;
   
   public class DependecyInversion {
   
   public static void main(String[] args) {
   //客户端无需改变
   Person person = new Person(); person.receive(new Email());
   
   person.receive(new WeiXin());
   }
   
   }
   
   //定义接口
   interface IReceiver { public String getInfo();
   }
   
   class Email implements IReceiver { public String getInfo() {
   return “电子邮件信息: hello,world”;
   }
   } | | —- |

依赖关系传递的三种方式和应用案例

1. 接口传递

应用案例代码

1. 构造方法传递应用案例代码

2. setter 方式传递

应用案例代码

1. 代码演示 | package com.atguigu.principle.inversion.improve;
   
   public class DependencyPass {
   
   public static void main(String[] args) {
   // TODO Auto-generated method stub ChangHong changHong = new ChangHong();
   // OpenAndClose openAndClose = new OpenAndClose();
   // openAndClose.open(changHong);
   
   //通过构造器进行依赖传递
   // OpenAndClose openAndClose = new OpenAndClose(changHong);
   // openAndClose.open();
   //通过 setter 方法进行依赖传递
   OpenAndClose openAndClose = new OpenAndClose(); openAndClose.setTv(changHong); openAndClose.open();
   
   }
   
   }
   
   // 方式 1： 通过接口传递实现依赖
   // 开关的接口 | | —- |

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

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

里氏替换原则

OO 中的继承性的思考和说明

1. 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。

2. 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低， 增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障

3. 问题提出：在编程中，如何正确的使用继承? => 里氏替换原则

基本介绍

1. 里氏替换原则(Liskov Substitution Principle)在 1988 年，由麻省理工学院的以为姓里的女士提出的。

2. 如果对每个类型为 T1 的对象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。

3. 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法

4. 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖 来解决问题。.

一个程序引出的问题和思考

该看个程序, 思考下问题和解决思路

解决方法

1. 我们发现原来运行正常的相减功能发生了错误。原因就是类 B 无意中重写了父类的方法，造成原有功能出现错误。在实际编程中，我们常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的

复用性会比较差。特别是运行多态比较频繁的时候

1. 通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖，聚合，组合等关系代替.
2. 改进方案

代码实现

开闭原则

基本介绍

1. 开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则
2. 一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。

3. 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

4. 编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。

看下面一段代码

• 看一个画图形的功能。类图设计，如下:

• 代码演示 | package com.atguigu.principle.ocp;
  
  public class Ocp {
  
  public static void main(String[] args) {
  //使用看看存在的问题
  GraphicEditor graphicEditor = new GraphicEditor(); | | —- |

方式 1 的优缺点

1. 优点是比较好理解，简单易操作。
2. 缺点是违反了设计模式的 ocp 原则，即对扩展开放(提供方)，对修改关闭(使用方)。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码.
3. 比如我们这时要新增加一个图形种类 三角形，我们需要做如下修改，修改的地方较多
4. 代码演示

方式 1 的改进的思路分析

改进的思路分析

思路：把创建 Shape 类做成抽象类，并提供一个抽象的 draw 方法，让子类去实现即可，这样我们有新的图形种类时，只需要让新的图形类继承 Shape，并实现 draw 方法即可，使用方的代码就不需要修 -> 满足了开闭原则
改进后的代码：

迪米特法则

基本介绍

1. 一个对象应该对其他对象保持最少的了解
2. 类与类关系越密切，耦合度越大
3. 迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息

4. 迪米特法则还有个更简单的定义：只与直接的朋友通信

5. 直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

应用实例

1. 有一个学校，下属有各个学院和总部，现要求打印出学校总部员工 ID 和学院员工的 id
2. 编程实现上面的功能, 看代码演示
3. 代码演示 | package com.atguigu.principle.demeter;
   
   import java.util.ArrayList; import java.util.List;
   
   //客户端 | | —- |

应用实例改进

1. 前面设计的问题在于 SchoolManager 中，CollegeEmployee 类并不是 SchoolManager 类的直接朋友 (分析)
2. 按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合
3. 对代码按照迪米特法则 进行改进. (看老师演示)
4. 代码演示 | package com.atguigu.principle.demeter.improve; | | —- |

迪米特法则注意事项和细节

1. 迪米特法则的核心是降低类之间的耦合
2. 但是注意：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间(对象间)耦合关系， 并不是要求完全没有依赖关系

合成复用原则（Composite Reuse Principle）

基本介绍

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

设计原则核心思想

1. 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2. 针对接口编程，而不是针对实现编程。

3. 为了交互对象之间的松耦合设计而努力

   第 3 章 UML 类图

   UML 基本介绍

4. UML——Unified modeling language UML (统一建模语言)，是一种用于软件系统分析和设计的语言工具，它用于帮助软件开发人员进行思考和记录思路的结果

5. UML 本身是一套符号的规定，就像数学符号和化学符号一样，这些符号用于描述软件模型中的各个元素和他们之间的关系，比如类、接口、实现、泛化、依赖、组合、聚合等，如右图:

1. 使用 UML 来建模，常用的工具有 Rational Rose , 也可以使用一些插件来建模

Eclipse 安装 UML插件(AmaterasUML).zip

AmaterasUML_1.3.4.rar

UML 图

画 UML 图与写文章差不多，都是把自己的思想描述给别人看，关键在于思路和条理，UML 图分类：

1. 用例图(use case)
2. 静态结构图：类图、对象图、包图、组件图、部署图
3. 动态行为图：交互图（时序图与协作图）、状态图、活动图

• 说明：

1. 类图是描述类与类之间的关系的，是 UML 图中最核心的

2. 在讲解设计模式时，我们必然会使用类图，为了让学员们能够把设计模式学到位，需要先给大家讲解类图

3. 温馨提示：如果已经掌握 UML 类图的学员，可以直接听设计模式的章节

UML 类图

1. 用于描述系统中的类(对象)本身的组成和类(对象)之间的各种静态关系。
2. 类之间的关系：依赖、泛化（继承）、实现、关联、聚合与组合。
3. 类图简单举例

public class Person{ //代码形式->类图
private Integer id; private String name;
public void setName(String name){ this.name=name;
}
public String getName(){ return name;
}
}

类图—依赖关系（Dependence）

• 只要是在类中用到了对方，那么他们之间就存在依赖关系。如果没有对方，连编绎都通过不了。

public class PersonServiceBean { private PersonDao personDao;//类public void save(Person person){}
public IDCard getIDCard(Integer personid){} public void modify(){
Department department = new Department();
}

}
public class PersonDao{} public class IDCard{} public class Person{} public class Department{}

• 对应的类图：

• 小结

1. 类中用到了对方
2. 如果是类的成员属性
3. 如果是方法的返回类型
4. 是方法接收的参数类型
5. 方法中使用到

   类图—泛化关系(generalization）

• 泛化关系实际上就是继承关系，他是依赖关系的特例

public abstract class DaoSupport{ public void save(Object entity){
}
public void delete(Object id){
}

}

public class PersonServiceBean extends Daosupport{
}

• 对应的类图

• 小结:

1. 泛化关系实际上就是继承关系
2. 如果 A 类继承了 B 类，我们就说 A 和 B 存在泛化关系

   类图—实现关系（Implementation）

   实现关系实际上就是 A 类实现 B 接口，他是依赖关系的特例
   public interface PersonService { public void delete(Interger id);
   }
   public class PersonServiceBean implements PersonService { public void delete(Interger id){}
   }
   =>类图
   
   小结:

类图—关联关系（Association）

类图—聚合关系（Aggregation）

基本介绍

聚合关系（Aggregation）表示的是整体和部分的关系，整体与部分可以分开。聚合关系是关联关系的特例，所以他具有关联的导航性与多重性。
如：一台电脑由键盘(keyboard)、显示器(monitor)，鼠标等组成；组成电脑的各个配件是可以从电脑上分离出来的，使用带空心菱形的实线来表示：

应用实例

类图—组合关系（Composition）

基本介绍

组合关系：也是整体与部分的关系，但是整体与部分不可以分开。
再看一个案例：在程序中我们定义实体：Person 与 IDCard、Head, 那么 Head 和 Person 就是 组合，IDCard 和
Person 就是聚合。

但是如果在程序中 Person 实体中定义了对 IDCard 进行级联删除，即删除 Person 时连同 IDCard 一起删除，那么 IDCard 和 Person 就是组合了.

应用案例

对应的类图:

案例 2

第 4 章 设计模式概述

掌握设计模式的层次

1. 第 1 层：刚开始学编程不久，听说过什么是设计模式

2. 第 2 层：有很长时间的编程经验，自己写了很多代码，其中用到了设计模式，但是自己却不知道

3. 第 3 层：学习过了设计模式，发现自己已经在使用了，并且发现了一些新的模式挺好用的

4. 第 4 层：阅读了很多别人写的源码和框架，在其中看到别人设计模式，并且能够领会设计模式的精妙和带来的好处。
5. 第 5 层：代码写着写着，自己都没有意识到使用了设计模式，并且熟练的写了出来。

设计模式介绍

1. 设计模式是程序员在面对同类软件工程设计问题所总结出来的有用的经验，模式不是代码，而是某类问题的通用解决方案，设计模式（Design pattern）代表了最佳的实践。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

2. 设计模式的本质提高 软件的维护性，通用性和扩展性，并降低软件的复杂度。

3. <<设计模式>> 是经典的书，作者是 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides Design（俗称 “四人组 GOF”）
4. 设计模式并不局限于某种语言，java，php，c++ 都有设计模式.

设计模式类型

设计模式分为三种类型，共 23 种

1. 创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式。

1. 结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
2. 行为型模式：模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter 模式）、状态模式、策略模式、职责链模式(责任链模式)。

注意：不同的书籍上对分类和名称略有差别

第 5 章 单例设计模式

单例设计模式介绍

所谓类的单例设计模式，就是采取一定的方法保证在整个的软件系统中，对某个类只能存在一个对象实例， 并且该类只提供一个取得其对象实例的方法(静态方法)。

比如 Hibernate 的 SessionFactory，它充当数据存储源的代理，并负责创建 Session 对象。SessionFactory 并不是轻量级的，一般情况下，一个项目通常只需要一个 SessionFactory 就够，这是就会使用到单例模式。

单例设计模式八种方式

单例模式有八种方式：

1. 饿汉式(静态常量)
2. 饿汉式（静态代码块）
3. 懒汉式(线程不安全)
4. 懒汉式(线程安全，同步方法)
5. 懒汉式(线程安全，同步代码块)
6. 双重检查
7. 静态内部类
8. 枚举

饿汉式（静态常量）

饿汉式（静态常量）应用实例步骤如下：

1. 构造器私有化 (防止 new )
2. 类的内部创建对象
3. 向外暴露一个静态的公共方法。getInstance
4. 代码实现 | package com.atguigu.singleton.type1;
   
   public class SingletonTest01 {
   
   public static void main(String[] args) {
   //测试
   Singleton instance = Singleton.getInstance(); Singleton instance2 = Singleton.getInstance(); System.out.println(instance == instance2); // true
   System.out.println(“instance.hashCode=” + instance.hashCode()); System.out.println(“instance2.hashCode=” + instance2.hashCode());
   }
   
   }
   
   //饿汉式(静态变量) class Singleton {
   //1. 构造器私有化, 外部能 new private Singleton() { | | —- |

• 优缺点说明：

1. 优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。

2. 缺点：在类装载的时候就完成实例化，没有达到 Lazy Loading 的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费

3. 这种方式基于 classloder 机制避免了多线程的同步问题，不过，instance 在类装载时就实例化，在单例模式中大多数都是调用 getInstance 方法， 但是导致类装载的原因有很多种，因此不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化 instance 就没有达到 lazy loading 的效果

4. 结论：这种单例模式可用，可能造成内存浪费

饿汉式（静态代码块）

• 代码演示：

• 优缺点说明：

1. 这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面是一样的。
2. 结论：这种单例模式可用，但是可能造成内存浪费

懒汉式(线程不安全)

• 代码演示： | package com.atguigu.singleton.type3;
  
  
  public class SingletonTest03 { | | —- |

• 优缺点说明：

1. 起到了 Lazy Loading 的效果，但是只能在单线程下使用。
2. 如果在多线程下，一个线程进入了 if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式
3. 结论：在实际开发中，不要使用这种方式.

懒汉式(线程安全，同步方法)

• 代码演示： | package com.atguigu.singleton.type4;
  
  
  public class SingletonTest04 {
  
  public static void main(String[] args) {
  System.out.println(“懒汉式 2 ， 线程安全~”); Singleton instance = Singleton.getInstance(); Singleton instance2 = Singleton.getInstance(); System.out.println(instance == instance2); // true
  System.out.println(“instance.hashCode=” + instance.hashCode()); System.out.println(“instance2.hashCode=” + instance2.hashCode());
  }
  
  } | | —- |

• 优缺点说明：

1. 解决了线程安全问题
2. 效率太低了，每个线程在想获得类的实例时候，执行 getInstance()方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例，直接 return 就行了。方法进行同步效率太低
3. 结论：在实际开发中，不推荐使用这种方式

懒汉式(线程安全，同步代码块)

不推荐使用

双重检查

• 代码演示 | package com.atguigu.singleton.type6;
  
  
  public class SingletonTest06 {
  
  public static void main(String[] args) {
  System.out.println(“双重检查”);
  Singleton instance = Singleton.getInstance(); Singleton instance2 = Singleton.getInstance(); System.out.println(instance == instance2); // true
  System.out.println(“instance.hashCode=” + instance.hashCode());
  System.out.println(“instance2.hashCode=” + instance2.hashCode()); | | —- |

• 优缺点说明：

1. Double-Check 概念是多线程开发中常使用到的，如代码中所示，我们进行了两次 if (singleton == null)检查，这样就可以保证线程安全了。
2. 这样，实例化代码只用执行一次，后面再次访问时，判断 if (singleton == null)，直接 return 实例化对象，也避免的反复进行方法同步.
3. 线程安全；延迟加载；效率较高
4. 结论：在实际开发中，推荐使用这种单例设计模式

静态内部类

• 代码演示： | package com.atguigu.singleton.type7;
  
  
  public class SingletonTest07 {
  
  public static void main(String[] args) { System.out.println(“使用静态内部类完成单例模式”); Singleton instance = Singleton.getInstance();
  Singleton instance2 = Singleton.getInstance(); System.out.println(instance == instance2); // true System.out.println(“instance.hashCode=” + instance.hashCode()); System.out.println(“instance2.hashCode=” + instance2.hashCode());
  
  } | | —- |

• 优缺点说明：

1. 这种方式采用了类装载的机制来保证初始化实例时只有一个线程。
2. 静态内部类方式在 Singleton 类被装载时并不会立即实例化，而是在需要实例化时，调用 getInstance 方法，才会装载 SingletonInstance 类，从而完成 Singleton 的实例化。
3. 类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM 帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。
4. 优点：避免了线程不安全，利用静态内部类特点实现延迟加载，效率高
5. 结论：推荐使用.

   枚举

• 代码演示 | package com.atguigu.singleton.type8;
  
  public class SingletonTest08 {
  public static void main(String[] args) { Singleton instance = Singleton.INSTANCE;
  Singleton instance2 = Singleton.INSTANCE; System.out.println(instance == instance2);
  
  System.out.println(instance.hashCode()); System.out.println(instance2.hashCode());
  
  instance.sayOK();
  }
  }
  
  //使用枚举，可以实现单例, 推荐
  enum Singleton { | | —- |

• 优缺点说明：

1. 这借助 JDK1.5 中添加的枚举来实现单例模式。不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。
2. 这种方式是 Effective Java 作者 Josh Bloch 提倡的方式

3. 结论：推荐使用

   单例模式在 JDK 应用的源码分析

   5.11.1 单例模式在 JDK 应用的源码分析

4. 我们 JDK 中，java.lang.Runtime 就是经典的单例模式(饿汉式)

5. 代码分析+Debug 源码+代码说明

   单例模式注意事项和细节说明

6. 单例模式保证了 系统内存中该类只存在一个对象，节省了系统资源，对于一些需要频繁创建销毁的对象，使用单例模式可以提高系统性能

7. 当想实例化一个单例类的时候，必须要记住使用相应的获取对象的方法，而不是使用 new

8. 单例模式使用的场景：需要频繁的进行创建和销毁的对象、创建对象时耗时过多或耗费资源过多(即：重量级对象)，但又经常用到的对象、工具类对象、频繁访问数据库或文件的对象(比如数据源、session 工厂等)

   第 6 章 工厂模式

   简单工厂模式

   看一个具体的需求

看一个披萨的项目：要便于披萨种类的扩展，要便于维护

1. 披萨的种类很多(比如 GreekPizz、CheesePizz 等)
2. 披萨的制作有 prepare，bake, cut, box
3. 完成披萨店订购功能。

使用传统的方式来完成

1. 思路分析(类图)

编写 OrderPizza.java 去订购需要的各种 Pizza

1. 看老师代码的演示 | public class OrderPizza { | | —- |

传统的方式的优缺点

1. 优点是比较好理解，简单易操作。
2. 缺点是违反了设计模式的 ocp 原则，即对扩展开放，对修改关闭。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码.

3. 比如我们这时要新增加一个 Pizza 的种类(Pepper 披萨)，我们需要做如下修改. 如果我们增加一个 Pizza 类，只要是订购 Pizza 的代码都需要修改.

4. 改进的思路分析

分析：修改代码可以接受，但是如果我们在其它的地方也有创建 Pizza 的代码，就意味着，也需要修改，而创建 Pizza
的代码，往往有多处。
思路：把创建 Pizza 对象封装到一个类中，这样我们有新的 Pizza 种类时，只需要修改该类就可，其它有创建到 Pizza
对象的代码就不需要修改了.-> 简单工厂模式

基本介绍

1. 简单工厂模式是属于创建型模式，是工厂模式的一种。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式
2. 简单工厂模式：定义了一个创建对象的类，由这个类来封装实例化对象的行为(代码)
3. 在软件开发中，当我们会用到大量的创建某种、某类或者某批对象时，就会使用到工厂模式.

使用简单工厂模式

1. 简单工厂模式的设计方案: 定义一个可以实例化 Pizaa 对象的类，封装创建对象的代码。

1. 看代码示例 | package com.atguigu.factory.simplefactory.pizzastore.order;
   
   import com.atguigu.factory.simplefactory.pizzastore.pizza.CheesePizza; import com.atguigu.factory.simplefactory.pizzastore.pizza.GreekPizza; import com.atguigu.factory.simplefactory.pizzastore.pizza.PepperPizza; import com.atguigu.factory.simplefactory.pizzastore.pizza.Pizza; | | —- |

工厂方法模式

看一个新的需求

披萨项目新的需求：客户在点披萨时，可以点不同口味的披萨，比如 北京的奶酪 pizza、北京的胡椒 pizza 或者是伦敦的奶酪 pizza、伦敦的胡椒 pizza。

思路 1

使用简单工厂模式，创建不同的简单工厂类，比如 BJPizzaSimpleFactory、LDPizzaSimpleFactory 等等.从当前这个案例来说，也是可以的，但是考虑到项目的规模，以及软件的可维护性、可扩展性并不是特别好

思路 2

使用工厂方法模式

工厂方法模式介绍

     1. 工厂方法模式设计方案：将披萨项目的实例化功能抽象成抽象方法，在不同的口味点餐子类中具体实现。
     1. 工厂方法模式：定义了一个创建对象的抽象方法，由子类决定要实例化的类。工厂方法模式将对象的实例化推迟到子类。

工厂方法模式应用案例

     1. 披萨项目新的需求：客户在点披萨时，可以点不同口味的披萨，比如 北京的奶酪 pizza、北京的胡椒 pizza 或者是伦敦的奶酪 pizza、伦敦的胡椒 pizza
     1. ![](https://cdn.nlark.com/yuque/0/2021/jpeg/393161/1626362603007-85a7310b-5479-4a58-be26-e16992b43f1a.jpeg#crop=0&crop=0&crop=1&crop=1&id=Wn4KZ&originHeight=483&originWidth=750&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)思路分析图解
     1. 看老师代码实现

抽象工厂模式

基本介绍

1. 抽象工厂模式：定义了一个 interface 用于创建相关或有依赖关系的对象簇，而无需指明具体的类
2. 抽象工厂模式可以将简单工厂模式和工厂方法模式进行整合。
3. 从设计层面看，抽象工厂模式就是对简单工厂模式的改进(或者称为进一步的抽象)。
4. 将工厂抽象成两层，AbsFactory(抽象工厂) 和 具体实现的工厂子类。程序员可以根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇，更利于代码的维护和扩展。
5. 类图

抽象工厂模式应用实例

使用抽象工厂模式来完成披萨项目.

工厂模式在 JDK-Calendar 应用的源码分析

1. JDK 中的 Calendar 类中，就使用了简单工厂模式
2. 源码分析+Debug 源码+说明

• 源码部分 | package com.atguigu.jdk;
  
  import java.util.Calendar;
  
  public class Factory {
  
  public static void main(String[] args) {
  // TODO Auto-generated method stub
  // getInstance 是 Calendar 静态方法
  Calendar cal = Calendar.getInstance();
  // 注意月份下标从 0 开始，所以取月份要+1
  System.out.println(“年:” + cal.get(Calendar.YEAR));
  System.out.println(“ 月 :” + (cal.get(Calendar.MONTH) + 1)); System.out.println(“日:” + cal.get(Calendar.DAY_OF_MONTH));
  System.out.println(“时:” + cal.get(Calendar.HOUR_OF_DAY));
  System.out.println(“分:” + cal.get(Calendar.MINUTE));
  System.out.println(“秒:” + cal.get(Calendar.SECOND));
  
  }
  
  } | | —- | | //Calendar.java |

工厂模式小结

1. 工厂模式的意义

将实例化对象的代码提取出来，放到一个类中统一管理和维护，达到和主项目的依赖关系的解耦。从而提高项目的扩展和维护性。

1. 三种工厂模式 (简单工厂模式、工厂方法模式、抽象工厂模式)
2. 设计模式的依赖抽象原则

• 创建对象实例时，不要直接 new 类, 而是把这个 new 类的动作放在一个工厂的方法中，并返回。有的书上说， 变量不要直接持有具体类的引用。
• 不要让类继承具体类，而是继承抽象类或者是实现 interface(接口)
• 不要覆盖基类中已经实现的方法。

  第 7 章 原型模式

  克隆羊问题

  现在有一只羊 tom，姓名为: tom, 年龄为：1，颜色为：白色，请编写程序创建和 tom 羊 属性完全相同的 10
  只羊。

  传统方式解决克隆羊问题

1. 思路分析(图解)

1. 看老师代码的演示 | package com.atguigu.prototype;
   
   public class Client {
   
   public static void main(String[] args) {
   // TODO Auto-generated method stub
   //传统的方法
   Sheep sheep = new Sheep(“tom”, 1, “白色”);
   
   Sheep sheep2 = new Sheep(sheep.getName(), sheep.getAge(), sheep.getColor()); Sheep sheep3 = new Sheep(sheep.getName(), sheep.getAge(), sheep.getColor()); Sheep sheep4 = new Sheep(sheep.getName(), sheep.getAge(), sheep.getColor()); | | —- |

传统的方式的优缺点

1. 优点是比较好理解，简单易操作。
2. 在创建新的对象时，总是需要重新获取原始对象的属性，如果创建的对象比较复杂时，效率较低
3. 总是需要重新初始化对象，而不是动态地获得对象运行时的状态, 不够灵活
4. 改进的思路分析

思路：Java 中 Object 类是所有类的根类，Object 类提供了一个 clone()方法，该方法可以将一个 Java 对象复制一份，但是需要实现 clone 的 Java 类必须要实现一个接口 Cloneable，该接口表示该类能够复制且具有复制的能力 =>原型模式

原型模式-基本介绍

基本介绍

1. 原型模式(Prototype 模式)是指：用原型实例指定创建对象的种类，并且通过拷贝这些原型，创建新的对象
2. 原型模式是一种创建型设计模式，允许一个对象再创建另外一个可定制的对象，无需知道如何创建的细节
3. 工作原理是:通过将一个原型对象传给那个要发动创建的对象，这个要发动创建的对象通过请求原型对象拷贝它们自己来实施创建，即 对象.clone()
4. 形象的理解：孙大圣拔出猴毛， 变出其它孙大圣

   原型模式原理结构图-uml 类图

   

• 原理结构图说明

1. Prototype : 原型类，声明一个克隆自己的接口
2. ConcretePrototype: 具体的原型类, 实现一个克隆自己的操作
3. Client: 让一个原型对象克隆自己，从而创建一个新的对象(属性一样）

原型模式解决克隆羊问题的应用实例

使用原型模式改进传统方式，让程序具有更高的效率和扩展性。

• 代码实现 | package com.atguigu.prototype.improve; | | —- |

原型模式在 Spring 框架中源码分析

1. Spring 中原型 bean 的创建，就是原型模式的应用
2. 代码分析+Debug 源码

深入讨论-浅拷贝和深拷贝

浅拷贝的介绍

1. 对于数据类型是基本数据类型的成员变量，浅拷贝会直接进行值传递，也就是将该属性值复制一份给新的对象。
2. 对于数据类型是引用数据类型的成员变量，比如说成员变量是某个数组、某个类的对象等，那么浅拷贝会进行引用传递，也就是只是将该成员变量的引用值（内存地址）复制一份给新的对象。因为实际上两个对象的该成员变量都指向同一个实例。在这种情况下，在一个对象中修改该成员变量会影响到另一个对象的该成员变量值
3. 前面我们克隆羊就是浅拷贝
4. 浅拷贝是使用默认的 clone()方法来实现

sheep = (Sheep) super.clone();

深拷贝基本介绍

1. 复制对象的所有基本数据类型的成员变量值

2. 为所有引用数据类型的成员变量申请存储空间，并复制每个引用数据类型成员变量所引用的对象，直到该对象可达的所有对象。也就是说，对象进行深拷贝要对整个对象(包括对象的引用类型)进行拷贝

3. 深拷贝实现方式 1：重写 clone 方法来实现深拷贝

4. 深拷贝实现方式 2：通过对象序列化实现深拷贝(推荐)

深拷贝应用实例

1. 使用 重写 clone 方法实现深拷贝
2. 使用序列化来实现深拷贝
3. 代码演示 | package com.atguigu.prototype.deepclone;
   
   import java.io.Serializable;
   
   public class DeepCloneableTarget implements Serializable, Cloneable {
   
   /** | | —- |

原型模式的注意事项和细节

1. 创建新的对象比较复杂时，可以利用原型模式简化对象的创建过程，同时也能够提高效率
2. 不用重新初始化对象，而是动态地获得对象运行时的状态
3. 如果原始对象发生变化(增加或者减少属性)，其它克隆对象的也会发生相应的变化，无需修改代码
4. 在实现深克隆的时候可能需要比较复杂的代码

5. 缺点：需要为每一个类配备一个克隆方法，这对全新的类来说不是很难，但对已有的类进行改造时，需要修改其源代码，违背了 ocp 原则，这点请同学们注意.

   第 8 章 建造者模式

   盖房项目需求

6. 需要建房子：这一过程为打桩、砌墙、封顶

7. 房子有各种各样的，比如普通房，高楼，别墅，各种房子的过程虽然一样，但是要求不要相同的.
8. 请编写程序，完成需求.

传统方式解决盖房需求

1. 思路分析(图解)

1. 看老师代码的演示 | package com.atguigu.builder;
   
   public abstract class AbstractHouse {
   
   //打地基
   public abstract void buildBasic(); | | —- |

传统方式的问题分析

1. 优点是比较好理解，简单易操作。
2. 设计的程序结构，过于简单，没有设计缓存层对象，程序的扩展和维护不好. 也就是说，这种设计方案，把产品(即：房子) 和 创建产品的过程(即：建房子流程) 封装在一起，耦合性增强了。
3. 解决方案：将产品和产品建造过程解耦 => 建造者模式.

建造者模式基本介绍

基本介绍

1. 建造者模式（Builder Pattern） 又叫生成器模式，是一种对象构建模式。它可以将复杂对象的建造过程抽象出来（抽象类别），使这个抽象过程的不同实现方法可以构造出不同表现（属性）的对象。
2. 建造者模式 是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们， 用户不需要知道内部的具体构建细节。

建造者模式的四个角色

1. Product（产品角色）： 一个具体的产品对象。

2. Builder（抽象建造者）： 创建一个 Product 对象的各个部件指定的 接口/抽象类。

3. ConcreteBuilder（具体建造者）： 实现接口，构建和装配各个部件。

4. Director（指挥者）： 构建一个使用 Builder 接口的对象。它主要是用于创建一个复杂的对象。它主要有两个作用，一是：隔离了客户与对象的生产过程，二是：负责控制产品对象的生产过程。

   建造者模式原理类图

建造者模式解决盖房需求应用实例

1. 需要建房子：这一过程为打桩、砌墙、封顶。不管是普通房子也好，别墅也好都需要经历这些过程，下面我们使用建造者模式(Builder Pattern)来完成
2. 思路分析图解(类图)

1. 代码实现

improve.zip

建造者模式在 JDK 的应用和源码分析

1. java.lang.StringBuilder 中的建造者模式
2. 代码说明+Debug 源码

1. 源码中建造者模式角色分析

• Appendable 接口定义了多个 append 方法(抽象方法), 即 Appendable 为抽象建造者, 定义了抽象方法
• AbstractStringBuilder 实现了 Appendable 接口方法，这里的 AbstractStringBuilder 已经是建造者，只是不能实例化
• StringBuilder 即充当了指挥者角色，同时充当了具体的建造者，建造方法的实现是由 AbstractStringBuilder 完成 , 而 StringBuilder 继承了 AbstractStringBuilder

建造者模式的注意事项和细节

1. 客户端(使用程序)不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象
2. 每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者， 用户使用不同的具体建造者即可得到不同的产品对象
3. 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰， 也更方便使用程序来控制创建过程
4. 增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合“开闭原则”
5. 建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。

6. 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大，因此在这种情况下，要考虑是否选择建造者模式.

7. 抽象工厂模式 VS 建造者模式

抽象工厂模式实现对产品家族的创建，一个产品家族是这样的一系列产品：具有不同分类维度的产品组合，采用抽象工厂模式不需要关心构建过程，只关心什么产品由什么工厂生产即可。而建造者模式则是要求按照指定的蓝图建造产品，它的主要目的是通过组装零配件而产生一个新产品

第 9 章 适配器设计模式

现实生活中的适配器例子

泰国插座用的是两孔的（欧标），可以买个多功能转换插头 (适配器) ，这样就可以使用了。

基本介绍

1. 适配器模式(Adapter Pattern)将某个类的接口转换成客户端期望的另一个接口表示，主的目的是兼容性，让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper)
2. 适配器模式属于结构型模式
3. 主要分为三类：类适配器模式、对象适配器模式、接口适配器模式

工作原理

1. 适配器模式：将一个类的接口转换成另一种接口.让原本接口不兼容的类可以兼容
2. 从用户的角度看不到被适配者，是解耦的
3. 用户调用适配器转化出来的目标接口方法，适配器再调用被适配者的相关接口方法
4. 用户收到反馈结果，感觉只是和目标接口交互，如图

类适配器模式

类适配器模式介绍

基本介绍：Adapter 类，通过继承 src 类，实现 dst 类接口，完成 src->dst 的适配。

类适配器模式应用实例

1. 应用实例说明

以生活中充电器的例子来讲解适配器，充电器本身相当于 Adapter，220V 交流电相当于 src (即被适配者)，我们的目 dst(即 目标)是 5V 直流电

1. 思路分析(类图)

1. 代码实现

classadapter.zip

类适配器模式注意事项和细节

1. Java 是单继承机制，所以类适配器需要继承 src 类这一点算是一个缺点, 因为这要求 dst 必须是接口，有一定局限性;
2. src 类的方法在 Adapter 中都会暴露出来，也增加了使用的成本。
3. 由于其继承了 src 类，所以它可以根据需求重写 src 类的方法，使得 Adapter 的灵活性增强了。

对象适配器模式

对象适配器模式介绍

1. 基本思路和类的适配器模式相同，只是将 Adapter 类作修改，不是继承 src 类，而是持有 src 类的实例，以解决兼容性的问题。 即：持有 src 类，实现 dst 类接口，完成 src->dst 的适配

2. 根据“合成复用原则”，在系统中尽量使用关联关系（聚合）来替代继承关系。

3. 对象适配器模式是适配器模式常用的一种

对象适配器模式应用实例

1. 应用实例说明

以生活中充电器的例子来讲解适配器，充电器本身相当于 Adapter，220V 交流电相当于 src (即被适配者)，我们的目 dst(即目标)是 5V 直流电，使用对象适配器模式完成。

1. 思路分析(类图)：只需修改适配器即可, 如下:

1. 代码实现

objectadapter.zip

对象适配器模式注意事项和细节

1. 对象适配器和类适配器其实算是同一种思想，只不过实现方式不同。

根据合成复用原则，使用组合替代继承， 所以它解决了类适配器必须继承 src 的局限性问题，也不再要求 dst
必须是接口。

1. 使用成本更低，更灵活。

接口适配器模式

接口适配器模式介绍

1. 一些书籍称为：适配器模式(Default Adapter Pattern)或缺省适配器模式。
2. 核心思路：当不需要全部实现接口提供的方法时，可先设计一个抽象类实现接口，并为该接口中每个方法提供一个默认实现（空方法），那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求

3. 适用于一个接口不想使用其所有的方法的情况。

   接口适配器模式应用实例

4. Android 中的属性动画 ValueAnimator 类可以通过 addListener(AnimatorListener listener)方法添加监听器， 那么常规写法如右：

5. 有时候我们不想实现 Animator.AnimatorListener 接口的全部方法，我们只想监听 onAnimationStart，我们会如下写

1. AnimatorListenerAdapter 类，就是一个接口适配器，代码如右图:它空实现了

Animator.AnimatorListener 类(src)的所有方法.

1. AnimatorListener 是一个接口.

1. 程序里的匿名内部类就是 Listener 具体实现类

1. 案例说明

适配器模式在 SpringMVC 框架应用的源码剖析

1. SpringMvc 中的 HandlerAdapter, 就使用了适配器模式
2. SpringMVC 处理请求的流程回顾
3. 使用 HandlerAdapter 的原因分析:

可以看到处理器的类型不同，有多重实现方式，那么调用方式就不是确定的，如果需要直接调用 Controller 方法，需要调用的时候就得不断是使用 if else 来进行判断是哪一种子类然后执行。那么如果后面要扩展 Controller， 就得修改原来的代码，这样违背了 OCP 原则。

1. 代码分析+Debug 源码

1. 动手写 SpringMVC 通过适配器设计模式获取到对应的 Controller 的源码

springmvc.zip 源码：

适配器模式的注意事项和细节

1. 三种命名方式，是根据 src 是以怎样的形式给到 Adapter（在 Adapter 里的形式）来命名的。
2. 类适配器：以类给到，在 Adapter 里，就是将 src 当做类，继承

对象适配器：以对象给到，在 Adapter 里，将 src 作为一个对象，持有接口适配器：以接口给到，在 Adapter 里，将 src 作为一个接口，实现

1. Adapter 模式最大的作用还是将原本不兼容的接口融合在一起工作。
2. 实际开发中，实现起来不拘泥于我们讲解的三种经典形式

   第 10 章桥接模式

   手机操作问题

   现在对不同手机类型的不同品牌实现操作编程(比如:开机、关机、上网，打电话等)，如图:
   

   传统方案解决手机操作问题

   传统方法对应的类图
   

传统方案解决手机操作问题分析

1. 扩展性问题(类爆炸)，如果我们再增加手机的样式(旋转式)，就需要增加各个品牌手机的类，同样如果我们增加一个手机品牌，也要在各个手机样式类下增加。
2. 违反了单一职责原则，当我们增加手机样式时，要同时增加所有品牌的手机，这样增加了代码维护成本.

3. 解决方案-使用桥接模式

   桥接模式(Bridge)-基本介绍

   基本介绍

4. 桥接模式(Bridge 模式)是指：将实现与抽象放在两个不同的类层次中，使两个层次可以独立改变。

5. 是一种结构型设计模式
6. Bridge 模式基于类的最小设计原则，通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现(Implementation)分离开来，从而可以保持各部分的独立性以及应对他们的功能扩展

   桥接模式(Bridge)-原理类图

• 上图做了说明

1. Client 类：桥接模式的调用者
2. 抽象类(Abstraction) :维护了 Implementor / 即它的实现类 ConcreteImplementorA.., 二者是聚合关系, Abstraction

充当桥接类

1. RefinedAbstraction : 是 Abstraction 抽象类的子类
2. Implementor : 行为实现类的接口
3. ConcreteImplementorA /B ：行为的具体实现类
4. 从 UML 图：这里的抽象类和接口是聚合的关系，其实调用和被调用关系

   桥接模式解决手机操作问题

使用桥接模式改进传统方式，让程序具有搞好的扩展性，利用程序维护

  1. 应用实例说明(和前面要求一样)
  1. ![](https://cdn.nlark.com/yuque/0/2021/jpeg/393161/1626362613251-7c8f865c-c58c-4414-b326-013372b627f1.jpeg#crop=0&crop=0&crop=1&crop=1&id=lb7aA&originHeight=289&originWidth=513&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)使用桥接模式对应的类图
  1. ![](https://cdn.nlark.com/yuque/0/2021/png/393161/1626362613546-7dacb0ab-ddcd-42f5-abfa-6caec8fa7903.png#crop=0&crop=0&crop=1&crop=1&id=uzQaF&originHeight=32&originWidth=32&originalType=binary&ratio=1&rotation=0&showTitle=false&status=done&style=none&title=)代码

bridge.zip

桥接模式在 JDBC 的源码剖析

桥接模式在 JDBC 的源码剖析

1. Jdbc 的 Driver 接口，如果从桥接模式来看，Driver 就是一个接口，下面可以有 MySQL 的 Driver，Oracle 的

Driver，这些就可以当做实现接口类

1. 代码分析+Debug 源码

• 对 jdbc 源码分析的类图

桥接模式的注意事项和细节

1. 实现了抽象和实现部分的分离，从而极大的提供了系统的灵活性，让抽象部分和实现部分独立开来，这有助于系统进行分层设计，从而产生更好的结构化系统。
2. 对于系统的高层部分，只需要知道抽象部分和实现部分的接口就可以了，其它的部分由具体业务来完成。
3. 桥接模式替代多层继承方案，可以减少子类的个数，降低系统的管理和维护成本。
4. 桥接模式的引入增加了系统的理解和设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计和编程
5. 桥接模式要求正确识别出系统中两个独立变化的维度(抽象、和实现)，因此其使用范围有一定的局限性，即需要有这样的应用场景。

桥接模式其它应用场景

对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用.

常见的应用场景:

  1. -JDBC 驱动程序
  1. -银行转账系统

转账分类: 网上转账，柜台转账，AMT 转账
转账用户类型：普通用户，银卡用户，金卡用户..

  1. -消息管理

消息类型：即时消息，延时消息
消息分类：手机短信，邮件消息，QQ 消息…

第 11 章装饰者设计模式

星巴克咖啡订单项目（咖啡馆）：

1. 咖啡种类/单品咖啡：Espresso(意大利浓咖啡)、ShortBlack、LongBlack(美式咖啡)、Decaf(无因咖啡)
2. 调料：Milk、Soy(豆浆)、Chocolate
3. 要求在扩展新的咖啡种类时，具有良好的扩展性、改动方便、维护方便

4. 使用 OO 的来计算不同种类咖啡的费用: 客户可以点单品咖啡，也可以单品咖啡+调料组合。

   方案 1-解决星巴克咖啡订单项目

   方案 1-解决星巴克咖啡订单问题分析

5. Drink 是一个抽象类，表示饮料

6. des 就是对咖啡的描述, 比如咖啡的名字
7. cost() 方法就是计算费用，Drink 类中做成一个抽象方法.
8. Decaf 就是单品咖啡， 继承 Drink, 并实现 cost
9. Espress && Milk 就是单品咖啡+调料， 这个组合很多
10. 问题：这样设计，会有很多类，当我们增加一个单品咖啡，或者一个新的调料，类的数量就会倍增，就会出现类爆炸

方案 2-解决星巴克咖啡订单(好点)

  1. 前面分析到方案 1 因为咖啡单品+调料组合会造成类的倍增，因此可以做改进，将调料内置到 Drink 类，这样就不会造成类数量过多。从而提高项目的维护性(如图)

  1. 说明: milk,soy,chocolate 可以设计为 Boolean,表示是否要添加相应的调料.

方案 2-解决星巴克咖啡订单问题分析

1. 方案 2 可以控制类的数量，不至于造成很多的类
2. 在增加或者删除调料种类时，代码的维护量很大
3. 考虑到用户可以添加多份 调料时，可以将 hasMilk 返回一个对应 int
4. 考虑使用 装饰者 模式

装饰者模式定义

1. 装饰者模式：动态的将新功能附加到对象上。在对象功能扩展方面，它比继承更有弹性，装饰者模式也体现了开闭原则(ocp)

2. 这里提到的动态的将新功能附加到对象和 ocp 原则，在后面的应用实例上会以代码的形式体现，请同学们注意体会。

   装饰者模式原理

   1. 装饰者模式就像打包一个快递

主体：比如：陶瓷、衣服 (Component) // 被装饰者
包装：比如：报纸填充、塑料泡沫、纸板、木板(Decorator)

  1. Component 主体：比如类似前面的 Drink
  1. ConcreteComponent 和 Decorator

ConcreteComponent：具体的主体， 比如前面的各个单品咖啡

  1. Decorator: 装饰者，比如各调料.

在如图的 Component 与 ConcreteComponent 之间，如果 ConcreteComponent 类很多,还可以设计一个缓冲层，将共有的部分提取出来，抽象层一个类。

装饰者模式解决星巴克咖啡订单

装饰者模式下的订单：2 份巧克力+一份牛奶的 LongBlack

装饰者模式咖啡订单项目应用实例

咖啡订单项目包结构

decorator.zip

装饰者模式在 JDK 应用的源码分析

Java 的 IO 结构，FilterInputStream 就是一个装饰者

源码说明

第 12 章组合模式

看一个学校院系展示需求

编写程序展示一个学校院系结构：需求是这样，要在一个页面中展示出学校的院系组成，一个学校有多个学院， 一个学院有多个系。如图：

传统方案解决学校院系展示(类图)

传统方案解决学校院系展示存在的问题分析

1. 将学院看做是学校的子类，系是学院的子类，这样实际上是站在组织大小来进行分层次的
2. 实际上我们的要求是 ：在一个页面中展示出学校的院系组成，一个学校有多个学院，一个学院有多个系， 因

此这种方案，不能很好实现的管理的操作，比如对学院、系的添加，删除，遍历等

1. 解决方案：把学校、院、系都看做是组织结构，他们之间没有继承的关系，而是一个树形结构，可以更好的实现管理操作。 => 组合模式

   组合模式基本介绍

   基本介绍

2. 组合模式（Composite Pattern），又叫部分整体模式，它创建了对象组的树形结构，将对象组合成树状结构以表示“整体-部分”的层次关系。

3. 组合模式依据树形结构来组合对象，用来表示部分以及整体层次。

4. 这种类型的设计模式属于结构型模式。
5. 组合模式使得用户对单个对象和组合对象的访问具有一致性，即：组合能让客户以一致的方式处理个别对象以及组合对象

组合模式原理类图

对原理结构图的说明-即(组合模式的角色及职责)

1. Component :这是组合中对象声明接口，在适当情况下，实现所有类共有的接口默认行为,用于访问和管理

Component 子部件, Component 可以是抽象类或者接口

1. Leaf : 在组合中表示叶子节点，叶子节点没有子节点

2. Composite :非叶子节点， 用于存储子部件， 在 Component 接口中实现 子部件的相关操作，比如增加(add), 删除。

   组合模式解决学校院系展示的 应用实例

   应用实例要求

3. 编写程序展示一个学校院系结构：需求是这样，要在一个页面中展示出学校的院系组成，一个学校有多个学院， 一个学院有多个系。

4. 思路分析和图解(类图)

1. 代码实现

composite.zip

组合模式在 JDK 集合的源码分析

1. Java 的集合类-HashMap 就使用了组合模式
2. 代码分析+Debug 源码

1. 类图

   组合模式的注意事项和细节

2. 简化客户端操作。客户端只需要面对一致的对象而不用考虑整体部分或者节点叶子的问题。

3. 具有较强的扩展性。当我们要更改组合对象时，我们只需要调整内部的层次关系，客户端不用做出任何改动.
4. 方便创建出复杂的层次结构。客户端不用理会组合里面的组成细节，容易添加节点或者叶子从而创建出复杂的树形结构
5. 需要遍历组织机构，或者处理的对象具有树形结构时, 非常适合使用组合模式.
6. 要求较高的抽象性，如果节点和叶子有很多差异性的话，比如很多方法和属性都不一样，不适合使用组合模式

   第 13 章外观模式

   影院管理项目

   组建一个家庭影院：
   DVD 播放器、投影仪、自动屏幕、环绕立体声、爆米花机,要求完成使用家庭影院的功能，其过程为： 直接用遥控器：统筹各设备开关
   开爆米花机放 下 屏 幕 开 投 影 仪 开音响
   开 DVD，选 dvd
   去拿爆米花调 暗 灯 光 播放
   观影结束后，关闭各种设备

   传统方式解决影院管理

   

传统方式解决影院管理问题分析

1. 在 ClientTest 的 main 方法中，创建各个子系统的对象，并直接去调用子系统(对象)相关方法，会造成调用过程混乱，没有清晰的过程
2. 不利于在 ClientTest 中，去维护对子系统的操作
3. 解决思路：定义一个高层接口，给子系统中的一组接口提供一个一致的界面(比如在高层接口提供四个方法

ready, play, pause, end )，用来访问子系统中的一群接口

1. 也就是说 就是通过定义一个一致的接口(界面类)，用以屏蔽内部子系统的细节，使得调用端只需跟这个接口发生调用，而无需关心这个子系统的内部细节 => 外观模式

   外观模式基本介绍

   基本介绍

2. 外观模式（Facade），也叫“过程模式：外观模式为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用

3. 外观模式通过定义一个一致的接口，用以屏蔽内部子系统的细节，使得调用端只需跟这个接口发生调用，而无需关心这个子系统的内部细节

外观模式原理类图

• 对类图说明(分类外观模式的角色)

1. 外观类(Facade): 为调用端提供统一的调用接口, 外观类知道哪些子系统负责处理请求,从而将调用端的请求代理给适当子系统对象
2. 调用者(Client): 外观接口的调用者
3. 子系统的集合：指模块或者子系统，处理 Facade 对象指派的任务，他是功能的实际提供者

外观模式解决影院管理

传统方式解决影院管理说明

1. 外观模式可以理解为转换一群接口，客户只要调用一个接口，而不用调用多个接口才能达到目的。比如：在 pc 上安装软件的时候经常有一键安装选项（省去选择安装目录、安装的组件等等），还有就是手机的重启功能（把关机和启动合为一个操作）。
2. 外观模式就是解决多个复杂接口带来的使用困难，起到简化用户操作的作用
3. 示意图说明

外观模式应用实例

1. 应用实例要求
2. 使用外观模式来完成家庭影院项目
3. 思路分析和图解(类图)
4. 代码实现

facade.zip

外观模式在 MyBatis 框架应用的源码分析

1. MyBatis 中的 Configuration 去创建 MetaObject 对象使用到外观模式
2. 代码分析+Debug 源码+示意图
3. 对源码中使用到的外观模式的角色类图

外观模式的注意事项和细节

1. 外观模式对外屏蔽了子系统的细节，因此外观模式降低了客户端对子系统使用的复杂性
2. 外观模式对客户端与子系统的耦合关系 - 解耦，让子系统内部的模块更易维护和扩展
3. 通过合理的使用外观模式，可以帮我们更好的划分访问的层次
4. 当系统需要进行分层设计时，可以考虑使用 Facade 模式
5. 在维护一个遗留的大型系统时，可能这个系统已经变得非常难以维护和扩展，此时可以考虑为新系统开发一个

Facade 类，来提供遗留系统的比较清晰简单的接口，让新系统与 Facade 类交互，提高复用性

1. 不能过多的或者不合理的使用外观模式，使用外观模式好，还是直接调用模块好。要以让系统有层次，利于维护为目的。

   第 14 章享元模式

   展示网站项目需求

   小型的外包项目，给客户 A 做一个产品展示网站，客户 A 的朋友感觉效果不错，也希望做这样的产品展示网站，但是要求都有些不同：

2. 有客户要求以新闻的形式发布

3. 有客户人要求以博客的形式发布
4. 有客户希望以微信公众号的形式发布

传统方案解决网站展现项目

1. 直接复制粘贴一份，然后根据客户不同要求，进行定制修改
2. 给每个网站租用一个空间
3. 方案设计示意图

传统方案解决网站展现项目-问题分析

1. 需要的网站结构相似度很高，而且都不是高访问量网站，如果分成多个虚拟空间来处理，相当于一个相同网站的实例对象很多，造成服务器的资源浪费
2. 解决思路：整合到一个网站中，共享其相关的代码和数据，对于硬盘、内存、CPU、数据库空间等服务器资源都可以达成共享，减少服务器资源
3. 对于代码来说，由于是一份实例，维护和扩展都更加容易

4. 上面的解决思路就可以使用 享元模式 来解决

   享元模式基本介绍

   基本介绍

5. 享元模式（Flyweight Pattern） 也叫 蝇量模式: 运用共享技术有效地支持大量细粒度的对象

6. 常用于系统底层开发，解决系统的性能问题。像数据库连接池，里面都是创建好的连接对象，在这些连接对象中有我们需要的则直接拿来用，避免重新创建，如果没有我们需要的，则创建一个
7. 享元模式能够解决重复对象的内存浪费的问题，当系统中有大量相似对象，需要缓冲池时。不需总是创建新对象，可以从缓冲池里拿。这样可以降低系统内存，同时提高效率
8. 享元模式经典的应用场景就是池技术了，String 常量池、数据库连接池、缓冲池等等都是享元模式的应用，享元模式是池技术的重要实现方式

享元模式的原理类图

• 对类图的说明

对原理图的说明-即(模式的角色及职责)

1. FlyWeight 是抽象的享元角色, 他是产品的抽象类, 同时定义出对象的外部状态和内部状态(后面介绍) 的接口或实现
2. ConcreteFlyWeight 是具体的享元角色，是具体的产品类，实现抽象角色定义相关业务
3. UnSharedConcreteFlyWeight 是不可共享的角色，一般不会出现在享元工厂。
4. FlyWeightFactory 享元工厂类，用于构建一个池容器(集合)， 同时提供从池中获取对象方法

内部状态和外部状态

比如围棋、五子棋、跳棋，它们都有大量的棋子对象，围棋和五子棋只有黑白两色，跳棋颜色多一点，所以棋子颜色就是棋子的内部状态；而各个棋子之间的差别就是位置的不同，当我们落子后，落子颜色是定的，但位置是变化的，所以棋子坐标就是棋子的外部状态

1. 享元模式提出了两个要求：细粒度和共享对象。这里就涉及到内部状态和外部状态了，即将对象的信息分为两个部分：内部状态和外部状态
2. 内部状态指对象共享出来的信息，存储在享元对象内部且不会随环境的改变而改变
3. 外部状态指对象得以依赖的一个标记，是随环境改变而改变的、不可共享的状态。
4. 举个例子：围棋理论上有 361 个空位可以放棋子，每盘棋都有可能有两三百个棋子对象产生，因为内存空间有限，一台服务器很难支持更多的玩家玩围棋游戏，如果用享元模式来处理棋子，那么棋子对象就可以减少到只有两个实例，这样就很好的解决了对象的开销问题

享元模式解决网站展现项目

1. 应用实例要求

使用享元模式完成，前面提出的网站外包问题

1. 思路分析和图解(类图)

1. 代码实现

flyweight.zip

享元模式在 JDK-Interger 的应用源码分析

1. Integer 中的享元模式
2. 代码分析+Debug 源码+说明

• 代码说明： | package com.atguigu.jdk;
  
  public class FlyWeight { | | —- |

享元模式的注意事项和细节

1. 在享元模式这样理解，“享”就表示共享，“元”表示对象
2. 系统中有大量对象，这些对象消耗大量内存，并且对象的状态大部分可以外部化时，我们就可以考虑选用享元模式
3. 用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象，用 HashMap/HashTable 存储
4. 享元模式大大减少了对象的创建，降低了程序内存的占用，提高效率
5. 享元模式提高了系统的复杂度。需要分离出内部状态和外部状态，而外部状态具有固化特性，不应该随着内部状态的改变而改变，这是我们使用享元模式需要注意的地方.
6. 使用享元模式时，注意划分内部状态和外部状态，并且需要有一个工厂类加以控制。

7. 享元模式经典的应用场景是需要缓冲池的场景，比如 String 常量池、数据库连接池

   第 15 章代理模式

   代理模式(Proxy)

   代理模式的基本介绍

8. 代理模式：为一个对象提供一个替身，以控制对这个对象的访问。即通过代理对象访问目标对象.这样做的好处是:可以在目标对象实现的基础上,增强额外的功能操作,即扩展目标对象的功能。

9. 被代理的对象可以是远程对象、创建开销大的对象或需要安全控制的对象
10. 代理模式有不同的形式, 主要有三种 静态代理、动态代理 (JDK 代理、接口代理)和 Cglib 代理 (可以在内存动态的创建对象，而不需要实现接口， 他是属于动态代理的范畴) 。
11. 代理模式示意图

静态代理

静态代码模式的基本介绍

静态代理在使用时,需要定义接口或者父类,被代理对象(即目标对象)与代理对象一起实现相同的接口或者是继承相同父类

应用实例

• 具体要求

1. 定义一个接口:ITeacherDao
2. 目标对象 TeacherDAO 实现接口 ITeacherDAO
3. 使用静态代理方式,就需要在代理对象 TeacherDAOProxy 中也实现 ITeacherDAO
4. 调用的时候通过调用代理对象的方法来调用目标对象.
5. 特别提醒：代理对象与目标对象要实现相同的接口,然后通过调用相同的方法来调用目标对象的方法

• 思路分析图解(类图)

• 代码实现

staticproxy.zip

静态代理优缺点

1. 优点：在不修改目标对象的功能前提下, 能通过代理对象对目标功能扩展
2. 缺点：因为代理对象需要与目标对象实现一样的接口,所以会有很多代理类
3. 一旦接口增加方法,目标对象与代理对象都要维护

动态代理

动态代理模式的基本介绍

1. 代理对象,不需要实现接口，但是目标对象要实现接口，否则不能用动态代理
2. 代理对象的生成，是利用 JDK 的 API，动态的在内存中构建代理对象
3. 动态代理也叫做：JDK 代理、接口代理

JDK 中生成代理对象的 API

1. 代理类所在包:java.lang.reflect.Proxy
2. JDK 实现代理只需要使用 newProxyInstance 方法,但是该方法需要接收三个参数,完整的写法是:

static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces,InvocationHandler h )

动态代理应用实例

• 应用实例要求

将前面的静态代理改进成动态代理模式(即：JDK 代理模式)

• 思路图解(类图)

• 代码实现

dynamic.zip

Cglib 代理

Cglib 代理模式的基本介绍

1. 静态代理和 JDK 代理模式都要求目标对象是实现一个接口,但是有时候目标对象只是一个单独的对象,并没有实现任何的接口,这个时候可使用目标对象子类来实现代理-这就是 Cglib 代理
2. Cglib 代理也叫作子类代理,它是在内存中构建一个子类对象从而实现对目标对象功能扩展, 有些书也将Cglib 代理归属到动态代理。
3. Cglib 是一个强大的高性能的代码生成包,它可以在运行期扩展 java 类与实现 java 接口.它广泛的被许多 AOP 的框架使用,例如 Spring AOP，实现方法拦截
4. 在 AOP 编程中如何选择代理模式：
   1. 目标对象需要实现接口，用 JDK 代理
   2. 目标对象不需要实现接口，用 Cglib 代理
5. Cglib 包的底层是通过使用字节码处理框架 ASM 来转换字节码并生成新的类

Cglib 代理模式实现步骤

1. 需要引入 cglib 的 jar 文件
2. 在内存中动态构建子类，注意代理的类不能为 final，否则报错java.lang.IllegalArgumentException:
3. 目标对象的方法如果为 final/static,那么就不会被拦截,即不会执行目标对象额外的业务方法.

   Cglib 代理模式应用实例

• 应用实例要求

将前面的案例用 Cglib 代理模式实现

• 思路图解(类图)
• 代码实现+Debug 源码[待 debug]

cglib.zip

几种常见的代理模式介绍— 几种变体

1. 防火墙代理

内网通过代理穿透防火墙，实现对公网的访问。

1. 缓存代理

比如：当请求图片文件等资源时，先到缓存代理取，如果取到资源则 ok,如果取不到资源，再到公网或者数据库取，然后缓存。

1. 远程代理

远程对象的本地代表，通过它可以把远程对象当本地对象来调用。远程代理通过网络和真正的远程对象沟通信息。

1. 同步代理：主要使用在多线程编程中，完成多线程间同步工作同步代理：主要使用在多线程编程中，完成多线程间同步工作

   第 16 章模板方法模式

   豆浆制作问题

   编写制作豆浆的程序，说明如下:

2. 制作豆浆的流程 选材—->添加配料—->浸泡—->放到豆浆机打碎

3. 通过添加不同的配料，可以制作出不同口味的豆浆
4. 选材、浸泡和放到豆浆机打碎这几个步骤对于制作每种口味的豆浆都是一样的
5. 请使用 模板方法模式 完成 (说明：因为模板方法模式，比较简单，很容易就想到这个方案，因此就直接使用， 不再使用传统的方案来引出模板方法模式 )

模板方法模式基本介绍

基本介绍

1. 模板方法模式（Template Method Pattern），又叫模板模式(Template Pattern)，z 在一个抽象类公开定义了执行它的方法的模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。
2. 简单说，模板方法模式 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构，就可以重定义该算法的某些特定步骤
3. 这种类型的设计模式属于行为型模式。

模板方法模式原理类图

16.3.1 模板方法模式的原理类图

• 对原理类图的说明-即(模板方法模式的角色及职责)

1. AbstractClass 抽象类， 类中实现了模板方法(template)，定义了算法的骨架，具体子类需要去实现 其它的抽象方法 operationr2,3,4
2. ConcreteClass 实现抽象方法 operationr2,3,4, 以完成算法中特点子类的步骤

模板方法模式解决豆浆制作问题

1. 应用实例要求

编写制作豆浆的程序，说明如下:
制作豆浆的流程 选材—->添加配料—->浸泡—->放到豆浆机打碎通过添加不同的配料，可以制作出不同口味的豆浆
选材、浸泡和放到豆浆机打碎这几个步骤对于制作每种口味的豆浆都是一样的(红豆、花生豆浆。。。)

1. 思路分析和图解(类图)

1. 代码实现

template.zip

模板方法模式的钩子方法

1. 在模板方法模式的父类中，我们可以定义一个方法，它默认不做任何事，子类可以视情况要不要覆盖它，该方法称为“钩子”。
2. 还是用上面做豆浆的例子来讲解，比如，我们还希望制作纯豆浆，不添加任何的配料，请使用钩子方法对前面的模板方法进行改造
3. 看老师代码演示：

improve.zip

模板方法模式在 Spring 框架应用的源码分析

1. Spring IOC 容器初始化时运用到的模板方法模式
2. 代码分析+角色分析+说明类图
3. 针对源码的类图(说明层次关系)

模板方法模式的注意事项和细节

1. 基本思想是：算法只存在于一个地方，也就是在父类中，容易修改。需要修改算法时，只要修改父类的模板方法或者已经实现的某些步骤，子类就会继承这些修改
2. 实现了最大化代码复用。父类的模板方法和已实现的某些步骤会被子类继承而直接使用。
3. 既统一了算法，也提供了很大的灵活性。父类的模板方法确保了算法的结构保持不变，同时由子类提供部分步骤的实现。
4. 该模式的不足之处：每一个不同的实现都需要一个子类实现，导致类的个数增加，使得系统更加庞大
5. 一般模板方法都加上 final 关键字， 防止子类重写模板方法.

6. 模板方法模式使用场景：当要完成在某个过程，该过程要执行一系列步骤 ，这一系列的步骤基本相同，但其个别步骤在实现时 可能不同，通常考虑用模板方法模式来处理

   第 17 章命令模式

   智能生活项目需求

   看一个具体的需求

7. 我们买了一套智能家电，有照明灯、风扇、冰箱、洗衣机，我们只要在手机上安装 app 就可以控制对这些家电工作。

8. 这些智能家电来自不同的厂家，我们不想针对每一种家电都安装一个 App，分别控制，我们希望只要一个 app

就可以控制全部智能家电。

1. 要实现一个 app 控制所有智能家电的需要，则每个智能家电厂家都要提供一个统一的接口给 app 调用，这时 就可以考虑使用命令模式。
2. 命令模式可将“动作的请求者”从“动作的执行者”对象中解耦出来.

3. 在我们的例子中，动作的请求者是手机 app，动作的执行者是每个厂商的一个家电产品

   命令模式基本介绍

4. 命令模式（Command Pattern）：在软件设计中，我们经常需要向某些对象发送请求，但是并不知道请求的接收者是谁，也不知道被请求的操作是哪个，

我们只需在程序运行时指定具体的请求接收者即可，此时，可以使用命令模式来进行设计

1. 命名模式使得请求发送者与请求接收者消除彼此之间的耦合，让对象之间的调用关系更加灵活，实现解耦。
2. 在命名模式中，会将一个请求封装为一个对象，以便使用不同参数来表示不同的请求(即命名)，同时命令模式也支持可撤销的操作。
3. 通俗易懂的理解：将军发布命令，士兵去执行。其中有几个角色：将军（命令发布者）、士兵（命令的具体执行者）、命令(连接将军和士兵)。

Invoker 是调用者（将军），Receiver 是被调用者（士兵），MyCommand 是命令，实现了 Command 接口，持有接收对象

命令模式的原理类图

• 对原理类图的说明-即(命名模式的角色及职责)

1. Invoker 是调用者角色
2. Command: 是命令角色，需要执行的所有命令都在这里，可以是接口或抽象类
3. Receiver: 接受者角色，知道如何实施和执行一个请求相关的操作

4. ConcreteCommand: 将一个接受者对象与一个动作绑定，调用接受者相应的操作，实现 execute

   命令模式解决智能生活项目

   应用实例要求

5. 编写程序，使用命令模式 完成前面的智能家电项目

6. 思路分析和图解

1. 代码实现

command.zip

• |

命令模式在 Spring 框架 JdbcTemplate 应用的源码分析

1. Spring 框架的 JdbcTemplate 就使用到了命令模式
2. 代码分析
3. 模式角色分析说明

• StatementCallback 接口 ,类似命令接口(Command)
• class QueryStatementCallback implements StatementCallback, SqlProvider , 匿名内部类， 实现了命令接口， 同时也充当命令接收者
• 命令调用者 是 JdbcTemplate , 其中 execute(StatementCallback action) 方法中，调用 action.doInStatement 方法. 不同的 实现 StatementCallback 接口的对象，对应不同的 doInStatemnt 实现逻辑
• 另外实现 StatementCallback 命令接口的子类还有 QueryStatementCallback、

命令模式的注意事项和细节

1. 将发起请求的对象与执行请求的对象解耦。发起请求的对象是调用者，调用者只要调用命令对象的 execute()方法就可以让接收者工作，而不必知道具体的接收者对象是谁、是如何实现的，命令对象会负责让接收者执行请求的动作，也就是说：”请求发起者”和“请求执行者”之间的解耦是通过命令对象实现的，命令对象起到了纽带桥梁的作用。
2. 容易设计一个命令队列。只要把命令对象放到列队，就可以多线程的执行命令
3. 容易实现对请求的撤销和重做
4. 命令模式不足：可能导致某些系统有过多的具体命令类，增加了系统的复杂度，这点在在使用的时候要注意
5. 空命令也是一种设计模式，它为我们省去了判空的操作。在上面的实例中，如果没有用空命令，我们每按下一个按键都要判空，这给我们编码带来一定的麻烦。

6. 命令模式经典的应用场景：界面的一个按钮都是一条命令、模拟 CMD（DOS 命令）订单的撤销/恢复、触发- 反馈机制

   第 18 章访问者模式

   测评系统的需求

   完成测评系统需求

7. 将观众分为男人和女人，对歌手进行测评，当看完某个歌手表演后，得到他们对该歌手不同的评价(评价 有不同的种类，比如 成功、失败 等)

8. 传统方案

   传统方式的问题分析

9. 如果系统比较小，还是 ok 的，但是考虑系统增加越来越多新的功能时，对代码改动较大，违反了 ocp 原则， 不利于维护

10. 扩展性不好，比如 增加了 新的人员类型，或者管理方法，都不好做

11. 引出我们会使用新的设计模式 – 访问者模式

    访问者模式基本介绍

12. 访问者模式（Visitor Pattern），封装一些作用于某种数据结构的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

13. 主要将数据结构与数据操作分离，解决 数据结构和操作耦合性问题

14. 访问者模式的基本工作原理是：在被访问的类里面加一个对外提供接待访问者的接口

15. 访问者模式主要应用场景是：需要对一个对象结构中的对象进行很多不同操作(这些操作彼此没有关联)，同时

需要避免让这些操作”污染”这些对象的类，可以选用访问者模式解决

访问者模式的原理类图

• 对原理类图的说明-

即(访问者模式的角色及职责)

1. Visitor 是抽象访问者，为该对象结构中的 ConcreteElement 的每一个类声明一个 visit 操作
2. ConcreteVisitor ：是一个具体的访问值 实现每个有 Visitor 声明的操作，是每个操作实现的部分.
3. ObjectStructure 能枚举它的元素， 可以提供一个高层的接口，用来允许访问者访问元素
4. Element 定义一个 accept 方法，接收一个访问者对象

5. ConcreteElement 为具体元素，实现了 accept 方法

   访问者模式应用实例

   应用实例要求

6. 将人分为男人和女人，对歌手进行测评，当看完某个歌手表演后，得到他们对该歌手不同的评价(评价 有不同的种类，比如 成功、失败 等)，请使用访问者模式来说实现

7. 思路分析和图解(类图)

1. 代码实现

visitor.zip

1. 应用案例的小结-双分派

-上面提到了双分派，所谓双分派是指不管类怎么变化，我们都能找到期望的方法运行。双分派意味着得到执行的操作取决于请求的种类和两个接收者的类型

• 以上述实例为例，假设我们要添加一个 Wait 的状态类，考察 Man 类和 Woman 类的反应，由于使用了双分派，只需增加一个 Action 子类即可在客户端调用即可，不需要改动任何其他类的代码。

  访问者模式的注意事项和细节

• 优点

1. 访问者模式符合单一职责原则、让程序具有优秀的扩展性、灵活性非常高
2. 访问者模式可以对功能进行统一，可以做报表、UI、拦截器与过滤器，适用于数据结构相对稳定的系统

• 缺点

1. 具体元素对访问者公布细节，也就是说访问者关注了其他类的内部细节，这是迪米特法则所不建议的, 这样造成了具体元素变更比较困难
2. 违背了依赖倒转原则。访问者依赖的是具体元素，而不是抽象元素

3. 因此，如果一个系统有比较稳定的数据结构，又有经常变化的功能需求，那么访问者模式就是比较合适的.

   第 19 章迭代器模式

   看一个具体的需求

   编写程序展示一个学校院系结构：需求是这样，要在一个页面中展示出学校的院系组成，一个学校有多个学院， 一个学院有多个系。如图：

   传统的设计方案(类图)

   

   传统的方式的问题分析

4. 将学院看做是学校的子类，系是学院的子类，这样实际上是站在组织大小来进行分层次的

5. 实际上我们的要求是 ：在一个页面中展示出学校的院系组成，一个学校有多个学院，一个学院有多个系， 因此这种方案，不能很好实现的遍历的操作

6. 解决方案：=> 迭代器模式

   迭代器模式基本介绍

   基本介绍

7. 迭代器模式（Iterator Pattern）是常用的设计模式，属于行为型模式

8. 如果我们的集合元素是用不同的方式实现的，有数组，还有 java 的集合类，或者还有其他方式，当客户端要遍历这些集合元素的时候就要使用多种遍历方式，而且还会暴露元素的内部结构，可以考虑使用迭代器模式解决。
9. 迭代器模式，提供一种遍历集合元素的统一接口，用一致的方法遍历集合元素，不需要知道集合对象的底层表示，即：不暴露其内部的结构。

   迭代器模式的原理类图