尚硅谷视频看到P43

设计模式七大原则：

目的：

1） 代码重用性（即：相同功能的代码，不用多次编写）

2）可读性（即：编程规划性，便于其他程序员的阅读和理解）

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

4） 可靠性（即：当我们增加新的功能后，对原来的功能没有影响）

5） 使程序呈现高内聚，低耦合的特性

单一职责原则

​ 「一个类只负责一项职责」

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

​ 1. 降低类的复杂度，一个类只负责一项职责。

​ 2.提高类的可读性、可维护性。

​ 3.降低变更引起的风险。

​ 4.通常情况下，我们应该遵守单一职责原则。

​ ——只有逻辑足够简单时，才可以在代码级违反单一职责原则；

​ ——只有类型的方法数量足够少时，才可以才方法级别保持单一职责原则。

接口隔离原则

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

​ 因为如果不是建立在最小的接口上，那么就说明有几个接口白白被实现了(实现但是没有被用)，违背了接口隔离原则！

image-20230523160645384

改进后：⬇️

image-20230523160702347

依赖倒转原则

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

  2. 抽象不应该依赖细节，细节应该依赖抽象

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

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

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

依赖关系传递的三种方式：你通过什么方式把接口的实现类传给你要使用的类

  • 接口传递(直接将对象作为方法的形参)
  • 构造方法传递(将对象在构造时存入待使用的类)
  • setter传递(set进去)

注意事项：

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

里氏替换原则

  1. 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
  1. 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障
  2. 问题提出：在编程中，如何正确的使用继承？=＞里氏替换原则

里氏替换原则的含义：所有引用基类的地方都能透明地使用其子类

​ ——子类尽量不重写父类的方法(重写后无法满足里氏替换原则)

​ ——如果你继承了然后还重写，那你何必继承呢？（除非迫不得已，不要重写父类方法）

在实际编程中，我们常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性比较差。特别是运行多态比较频繁的时候。

通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖，聚合，组合等

关系代替.

开闭原则

  • 是编程中最基础、最重要的设计原则

  • 一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。

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

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

迪米特法则

​ 基本介绍

  1. 一个对象应该对其他对象保持最少的了解

  2. 类与类关系越密切，耦合度越大

  3. 迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息

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

  5. 直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间

是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返

回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，**「陌生的类最好不要以局部变**

**量的形式出现在类的内部」**。

合成复用原则

​ 原则是尽量使用合成/聚合的方式，而不是使用继承(因为继承会增加耦合性)

场景：想让B使用A中的方法：

​ 我们当然可以让B继承A，但是这样会让A与B的耦合性增强

​ 我们可以采用以下方法：

  • 依赖：在B中添加以A为形参的方法，在该方法中使用A
  • 聚合：将A作为B类中的一个成员变量(构造函数/set方法)，在B的任意方法中使用A
  • 组合：将A作为B类中的一个成员变量，在创建B的时候直接new A(), new一个

总结：

​ 设计原则的核心思想：

  • 找出应用中的可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起
  • 针对接口编程，而不是针对实现编程
  • 为了交互对象之间的松耦合设计而努力

​

UML图：

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

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

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

类图用于描述类与类之间的关系，是UML图中的核心

UML类图

1） 用于描述系统中的类(对象)本身的组成和类(对象)之间的各种静态关系。

2） 类之间的关系：依赖、泛化(继承)、实现、关联、聚合与组合。

依赖关系：

​ 如果A类用到了B，则A与B存在依赖关系（如果没有对方，就无法编译通过）

  • 作为A的成员属性
  • 是A中方法的返回类型
  • 是A中方法的接收类型(形参类型)
  • 在A的方法中使用到(作为局部变量)

​ 用虚线箭头描述关系

泛化关系：

​ 即继承关系，是依赖关系的特例

用实线+空心三角形描述

实现关系：

​ 即接口的实现关系，也是依赖关系的特例
用虚线+空心三角形描述

关联关系：

​ 指类与类之间的联系，是依赖关系的特例

用于描述两个类之间的关系是单向还是双向的

聚合关系：

​ 表示整体与部分的关系，***整体和部分可以分开，是关联关系的特例*

1
2
3
4
//例如
class Computer{								//Computer中的Mouse可以为null
	Mouse mouse;
}

用实线+空心菱形描述

组合关系：

​ 表示整体与部分的关系，***整体和部分不可以分开***，则是组合关系

1
2
3
4
//例如
class Computer{									//Computer与Mouse 共创建、共销毁
	Mouse mouse = new Mouse();
}

用实线+黑菱形描述

设计模式概述：

掌握设计模式的层次：

  • 第1层：刚开始学编程不久，听说过什么是设计模式
  • 第2层：有很长时间的编程经验，自己写了很多代码，其中用到了设计模式，但是自己却不知道
  • 第3层：学习过了设计模式，发现自己己经在使用了，并且发现了一些新的模式挺好用的
  • 第4层：阅读了很多别人写的源码和框架，在其中看到别人设计模式，并且能够领会设计模式的精妙和带来的好处。
  • 第5层：代码写着写着，自己都没有意识到使用了设计模式，并且熟练的写了出来。

设计模式介绍：

  • 设计模式是程序员在面对同类软件工程设计问题所总结出来的有用的经验，模式不是代码，而是某类问题的通用解決方案，设计模式 (Design pattern）代表了最佳的实践。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
  • 设计模式的本质提高 软件的维护性，通用性和扩展性，并降低软件的复杂度。
  • ＜<设计模式>＞是经典的书，作者是 Erich Gamma、 Richard Helmn、 Ralph Johnson 和 John Vlissides Design （俗称“四人组 GOF”)
  • 设计模式并不局限于某种语言，java，php，c++ 都有设计模式.

设计模式详解：

创建型模式：

创建型： 在创建对象的同时隐藏创建逻辑，不使⽤ new 直接实例化对象，程序在判断需要创建哪些对象时更灵活。包括⼯⼚/抽象⼯⼚/单例/建造者/原型模式。

单例模式：

  1. 饿汉式(静态常量)

    • 构造器私有化 保证外部不能new

    • 类的内部创建静态对象 在类的内部创建该类的静态对象，在类加载时自动生成

    • 向外暴露一个静态的公共方法——getInstance

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

      缺点：在类装载的时候就完成实例化，没有达到Lazy Loading 的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费；正因为是在类加载时就会创建对象，我们可能在别的地方无意导致该类加载而不去使用，造成内存浪费。

  2. 饿汉式(静态代码块)

    • 在类中定义该类的静态变量

    • 在静态代码块中完成该类的静态变量的初始化

      优缺点分析：

      ​ 这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是 在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点与上面方法一样

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

  3. 懒汉式(线程不安全)

    • 构造器私有化 保证外部不能new

    • 类的内部定义静态对象 创建对象，但是不创建(不 new)

    • 向外暴露一个静态的公共方法——getInstance 在调用该方法时，才对该类的静态对象进行创建

      image-20230524105503814

      优缺点分析：

      ​ 起到了 Lazy Loading 的效果，但是只能在单线程下使用。

      ​ 如果在多线程下，一个线程进入了**if(singleton== null)**判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式。

      结论：在实际开发中，不要使用这种方式.

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

    给 getInstance 添加 synchronize 修饰，保证同步

    image-20230524112254631

    优缺点分析：

    ​ 解决了线程安全问题

    ​ 效率太低了，每个线程在想获得类的实例时候，执行 getinstance()方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例，直接 return 就行了。方法进行同步效率太低

    结论：在实际开发中，不推荐使用这种方式

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

    不可使用，因为不能保证单例

  6. 双重检查

    image-20230524114249721

    ​ Double-Check 概念是多线程开发中常使用到的，如代码中所示，我们进行了两次if(singleton== null)检查，这样就可以保证线程安全了。

    ​ 这样，实例化代码只用执行一次，后面再次访问时，判断if(singleton==null)，直接 return 实例化对象，也避免的反复进行方法同步.

    ​ 线程安全；延迟加载；效率较高

    结论：在实际开发中，推荐使用这种单例设计模式

    🌟这⾥为什么要使⽤ volatile ？

    这是因为 new 关键字创建对象不是原⼦操作，创建⼀个对象会经历下⾯的步骤：

    1. 在堆内存开辟内存空间
    2. 调⽤构造⽅法，初始化对象
    3. 引⽤变量指向堆内存空间
      为了提⾼性能，编译器和处理器常常会对既定的代码执⾏顺序进⾏指令重排序，从源码到最终执⾏指令会经历如下流程：
      源码编译器优化重排序指令级并⾏重排序内存系统重排序最终执⾏指令序列所以经过**指令重排序之后，创建对象的执⾏顺序可能为 1 2 3 或者 1 3 2 ，因此当某个线程在乱序运⾏ 1 3 2 指令的时候，引⽤变量指向堆内存空间，这个对象不为 null，但是没有初始化，其他线程有可能这个时候进⼊了 getInstance 的第⼀个 if(instance == null) 判断不为 nulll ，导致错误使⽤了没有初始化的⾮ null 实例**，这样的话就会出现异常，这个就是著名的
      DCL 失效问题。
      当我们在引⽤变量上⾯添加 volatile 关键字以后，会通过在创建对象指令的前后添加内存屏障来禁⽌指令重排序，就可以避免这个问题，⽽且对volatile 修饰的变量的修改对其他任何线程都是可⻅的。

  7. 静态内部类

    • 构造器私有化 保证外部不能new

    • 构建一个静态内部类，内部类中有一个静态属性，如果加载了静态类，该属性也会创建对象

    • 向外暴露一个静态的公共方法——getInstance 在调用该方法时，对静态内部类进行初始化，返回静态内部类属性

      image-20230524115554993

    优缺点分析：

    • 这种方式采用了类装载的机制来保证初始化实例时只有一个线程。

    • 静态内部类方式在 Singleton 类被装载时并不会立即实例化，而是在需要实例化时，调用 getinstance 方法，才会装载 Singletoninstance 类，从而完成 Singleton 的实例化。

    • 类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM 帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。

    • 优点：避免了线程不安全，利用静态内部类特点实现延迟加载，效率高

    • 缺点：getInstance 还是被synchronized修饰了

    结论：推荐使用．

  8. 枚举

    1
    2
    3
    4
    5
    6
    7
    //通过 Singleton.INSTANCE 来获取单例，获取的对象可以使用Singleton中的方法
    enum Singleton{
      INSTANCE;	//属性	
      public void func(){
        System.out.println("qwe");
      }
    }

    • 这借助 JDK1.5中添加的枚举来实现单例模式。不仅能避免多线程同步 问题，而且还能防止反序列化重新创建

    • 新的对象。

    • 这种方式是 Effective Java 作者 Josh Bloch 提倡的方式

    • 结论：推荐使用

    单例模式注意事项：

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

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

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

工厂模式：

简单工厂模式：

「针对每种产品」

简单⼯⼚模式指由⼀个⼯⼚对象来创建实例，客户端不需要关注创建逻辑，只需提供传⼊⼯⼚的参数。

  • 简单工厂模式是属于创建型模式，是工厂模式的一种。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式

  • 简单工厂模式：定义了一个创建对象的类，由这个类来封装实例化对象的行为

  • 在软件开发中，当我们用到大量的创建某种、某类或者某批对象时，就会使用到工厂模式.

工厂方法模式：

「针对一类产品」

和简单⼯⼚模式中⼯⼚负责⽣产所有产品相⽐，⼯⼚⽅法模式将⽣成具体产品的任务分发给具体的产品⼯⼚。

其实就是在工厂这边再分层 逻辑为：总工厂<–>子工厂1/2/3…

​ 其中，总工厂定义了产品的生产接口，而生产接口由不同的子工厂进行实现。从而对工厂进行了进一步划分。

抽象工厂模式：

「针对多类产品，每个类中还有多种产品！」

总工厂、子工厂都是抽象的。要生产某种产品，我们首先找到模版类似的子类，再对子类进行实现，从而进行创建。

结构型模式：

适配器模式：

概述：在我们的应⽤程序中我们可能需要将两个不同接⼝的类来进⾏通信，在不修改这两个的前提下我们可能会需要某个中间件来完成这个衔接的过程。这个中间件就是适配器。所谓适配器模式就是将⼀个类的接⼝，转换成客户期望的另⼀个接⼝。它可以让原本两个不兼容的接⼝能够⽆缝完成对接。

作为中间件的适配器将⽬标类和适配者解耦，增加了类的透明性和可复⽤性。

⽬标类和适配者不必有很大关联，可以通过适配器建立联系，从而实现解耦。

类适配器：
image-20230524201128653

对象适配器：

image-20230524201140631

  • Target: 定义 Client 真正需要使⽤的接⼝。

  • Adaptee: 其中定义了⼀个已经存在的接⼝，也是我们需要进⾏适配的接⼝。

  • Adapter: 对 Adaptee 和 Target 的接⼝进⾏适配，保证对 target 中接⼝的调⽤可以间接转换为对 Adaptee 中接⼝进⾏调⽤。

    • 优点：
    1. 提⾼了类的复⽤；
    2. 组合若⼲关联对象形成对外提供统⼀服务的接⼝；
    3. 扩展性、灵活性好。
    • 缺点：
    1. 过多使⽤适配模式容易造成代码功能和逻辑意义的混淆。
    2. 部分语⾔对继承的限制，可能⾄多只能适配⼀个适配者类，⽽且⽬标类必须是抽象类。

装饰模式：

装饰器模式主要对现有的类对象进⾏包裹和封装，以期望在不改变类对象及其类定义的情况下，为对象添加额外功能。是⼀种对象结构型模式。需要注意的是，该过程是通过调⽤被包裹之后的对象完成功能添加的，⽽不是直接修改现有对象的⾏为，相当于增加了中间层。(AOP???)

image-20230524204945734

Component: 对象的接⼝类，定义装饰对象和被装饰对象的共同接⼝；
ConcreteComponent: 被装饰对象的类定义；
Decorator: 装饰对象的抽象类，持有⼀个具体的被修饰对象，并实现接⼝类继承的公共接⼝；
ConcreteDecorator:具体的装饰器，负责往被装饰对象添加额外的功能；

讲讲装饰器模式的应⽤场景

如果你希望在⽆需修改代码的情况下即可使⽤对象， 且希望在运⾏时为对象新增额外的⾏为， 可以使⽤装饰模式。装饰能将业务逻辑组织为层次结构， 你可为各层创建⼀个装饰， 在运⾏时
将各种不同逻辑组合成对象。 由于这些对象都遵循通⽤接⼝， 客户端代码能以相同的⽅式使⽤这些对象。如果⽤继承来扩展对象⾏为的⽅案难以实现或者根本不可⾏， 你可以使⽤该模式。许多编程语⾔使⽤ final 最终关键字来限制对某个类的进⼀步扩展。 复⽤最终类已有⾏为的唯⼀⽅法是使⽤装饰模式： ⽤封装器对其进⾏封装。

代理模式：

代理模式的本质是⼀个中间件，主要⽬的是解耦合服务提供者和使⽤者。使⽤者通过代理间接地访问服务提供者，便于后者的封装和控制。是⼀种结构性模式。

image-20230524202229926

Subject: 定义 RealSubject 对外的接⼝，且这些接⼝必须被 Proxy 实现，这样外部调⽤ proxy 的接⼝最终都被转化为对 realsubject 的调⽤。
RealSubject: 真正的⽬标对象。
Proxy: ⽬标对象的代理，负责控制和管理⽬标对象，并间接地传递外部对⽬标对象的访问。

Remote Proxy: 对本地的请求以及参数进⾏序列化，向远程对象发送请求，并对响应结果进⾏反序列化，将最终结果反馈给调⽤者；
Virtual Proxy: 当⽬标对象的创建开销⽐较⼤的时候，可以使⽤延迟或者异步的⽅式创建⽬标对象；
Protection Proxy: 细化对⽬标对象访问权限的控制；

静态代理和动态代理的区别:

  1. 灵活性 ：动态代理更加灵活，不需要必须实现接⼝，可以直接代理实现类，并且可以不需要针对每个⽬标类都创建⼀个代理类。另外，静态代理中，接⼝⼀旦新增加⽅法，⽬标对象和代理对象都要进⾏修改，这是⾮常麻烦的！
  2. JVM 层⾯ ：静态代理在编译时就将接⼝、实现类、代理类这些都变成了⼀个个实际的 class ⽂件。⽽动态代理是在运⾏时动态⽣成类字节码，并加载到 JVM 中的。

行为型模式：

观察者模式：

观察者模式主要⽤于处理对象间的⼀对多的关系，是⼀种对象⾏为模式。

该模式的实际应⽤场景⽐较容易确认，当⼀个对象状态发⽣变化时，所有该对象的关注者均能收到状态变化通知，以进⾏相应的处理。(怎么这么像websocket啊)

image-20230524203754928

Subject: 抽象被观察者，仅提供注册和删除观察者对象的接⼝声明。
ConcreteSubject: 具体被观察者对象，该对象中收集了所有需要被通知的观察者，并可以动态的增删集合中的观察者。当其状态发⽣变化时会通知所有观察者对象。
Observer: 抽象观察者，为所有观察者定义获得通知的统⼀接⼝；
ConcreteObserver: 观察者对象，其关注对象为 Subject，能接受 Subject变化时发出的通知并更新⾃身状态。

  • 优点：
  1. 被观察者和观察者之间是抽象耦合的；
  2. 耦合度较低，两者之间的关联仅仅在于消息的通知；
  3. 被观察者⽆需关⼼他的观察者；
  4. ⽀持⼴播通信；
  • 缺点：
  1. 观察者只知道被观察对象发⽣了变化，但不知变化的过程和缘由；
  2. 观察者同时也可能是被观察者，消息传递的链路可能会过⻓，完成所有
    通知花费时间较多
  3. 如果观察者和被观察者之间产⽣循环依赖，或者消息传递链路形成闭
    环，会导致⽆限循环；

你的项⽬是怎么⽤的观察者模式？

在⽀付场景下，⽤户购买⼀件商品，当⽀付成功之后三⽅会回调⾃身，在这个时候系统可能会有很多需要执⾏的逻辑（如：更新订单状态，发送邮件通知，赠送礼品…），这些逻辑之间并没有强耦合，因此天然适合使⽤观察者模式去实现这些功能，当有更多的操作时，只需要添加新的观察者就能实现，完美实现了对修改关闭，对扩展开放的开闭原则。

责任链模式：

⼀个请求沿着⼀条“链”传递，直到该“链”上的某个处理者处理它为⽌。

讲讲责任链模式的应⽤场景

  • 当程序需要使⽤不同⽅式处理不同种类请求， ⽽且请求类型和顺序预先未知时， 可以使⽤责任链模式。该模式能将多个处理者连接成⼀条链。 接收到请求后， 它会 “询问” 每个处理者是否能够对其进⾏处理。这样所有处理者都有机会来处理请求。

  • 当必须按顺序执⾏多个处理者时， 可以使⽤该模式。 ⽆论你以何种顺序将处理者连接成⼀条链， 所有请求都会严格按照顺序通过链上的处理者。

策略模式

什么是策略模式？

策略模式（Strategy Pattern）属于对象的⾏为模式。其⽤意是针对⼀组算法，将每⼀个算法封装到具有共同接⼝的独⽴的类中，从⽽使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发⽣变化。其主要⽬的是通过定义相似的算法，替换 if else 语句写法，并且可以随时相互替换。

策略模式有什么好处？

定义了⼀系列封装了算法、⾏为的对象，他们可以相互替换。举例： Java.util.List 就是定义了⼀个增（ add ）、删（ remove ）、改（ set ）、查（ indexOf ）策略，⾄于实现这个策略的ArrayList 、 LinkedList 等类，只是在具体实现时采⽤了不同的算法。但因为它们策略⼀样，不考虑速度的情况下，使⽤时完全可以互相替换使⽤。

设计模式实例：

Spring 使⽤了哪些设计模式？

  • ⼯⼚设计模式 : Spring 使⽤⼯⼚模式通过BeanFactory 、 ApplicationContext 创建 bean 对象。
  • 代理设计模式 : Spring AOP 功能的实现(动态代理)。