第二十章 Spring之假如让你来写AOP——Aspect（切面）篇

本文链接：https://blog.csdn.net/weixin_42789334/article/details/143596818

Spring源码阅读目录

第一部分——IOC篇

第一章 Spring之最熟悉的陌生人——IOC
第二章 Spring之假如让你来写IOC容器——加载资源篇
第三章 Spring之假如让你来写IOC容器——解析配置文件篇
第四章 Spring之假如让你来写IOC容器——XML配置文件篇
第五章 Spring之假如让你来写IOC容器——BeanFactory和FactoryBean
第六章 Spring之假如让你来写IOC容器——Scope和属性填充
第七章 Spring之假如让你来写IOC容器——属性填充特别篇：SpEL表达式
第八章 Spring之假如让你来写IOC容器——拓展篇
第九章 Spring之源码阅读——环境搭建篇
第十章 Spring之源码阅读——IOC篇

第二部分——AOP篇

第三部分——事务篇

第二十五章 Spring之曾经的老朋友——事务
第二十六章 Spring之假如让你来写事务——初稿篇
第二十七章 Spring之假如让你来写事务——铁三角篇
第二十八章 Spring之假如让你来写事务——属性篇
第二十九章 Spring之假如让你来写事务——状态篇
第三十章 Spring之假如让你来写事务——管理篇
第三十一章 Spring之假如让你来写事务——融入IOC容器篇
第三十二章 Spring之源码阅读——事务篇

第四部分——MVC篇

第五部分——Boot篇

文章目录

Spring源码阅读目录
前言
尝试动手写IOC容器
- - 第二十版 Aspect（切面）篇
  - - 切点、通知的良媒——Advisor
    - 切面真正的管理者——Advised
总结

前言

对于Spring一直都是既熟悉又陌生，说对它熟悉吧，平时用用没啥问题，但面试的时候被问的一脸懵逼，就很尴尬，都不好意思在简历上写着熟悉Spring了
在这里插入图片描述

所以决定花点时间研究研究Spring的源码。主要参考的书籍是：《Spring源码深度解析（第2版）》、《Spring揭秘》、《Spring技术内幕：深入解析Spring架构与设计原理（第2版）》

书接上上回，在上上篇 第十八章 Spring之假如让你来写AOP——Advice（通知）下篇 中，A君废了老大的劲，终于实现了 Advice（通知） 的内容，虽然道路曲折，但是前途是光明的。接下来看看 A君会有什么骚操作吧

尝试动手写IOC容器

出场人物：A君（苦逼的开发）、老大（项目经理）

背景：老大要求A君在一周内开发个简单的 IOC容器

前情提要： A君已经完成 Advice（通知） 的内容。。。

第二十版 Aspect（切面）篇

“可以啊，A君！Advice（通知） 弄的出人意表，比我想象中的还好” 老大不吝夸赞道

“开玩笑，拼了老命才弄出来的。” A君心道

“接下来，我们来讨论下 Aspect（切面），Aspect（切面） 说到底，就是用来管理 Advice（通知） 的。这部分内容你自由发挥把，别忘了，面向接口编程，还有抽象类。” 老大今天难得没说什么，只是这“自由发挥”的要求也太抽象了

切点、通知的良媒——Advisor

开完会，A君独自坐在位置上思考：Aspect（切面） 要如何实现？直接定义一个接口，让它拥有CRUD的方法吗？A君随手写了个例子，如下：

import com.hqd.test.aop.Advice;
import com.hqd.test.aop.Pointcut;

import java.util.List;

public class Advisor {
   
    private List<Advice> adviceList;
    private List<Pointcut> pointcuts;

    public void addAdvice(Advice advice) {
   
        this.adviceList.add(advice);
    }

    public void addPointcut(Pointcut pointcut) {
   
        this.pointcuts.add(pointcut);
    }
}

额，不太对头，这无法知道 Advice（通知） 和 Pointcut（切点） 的对应关系。通过Map封装？这又不好管理了。算了，A君索性把 Advice（通知） 和 Pointcut（切点） 包装成一个类，这样方便管理。A君定个 Advisor 接口，用以维护 Advice（通知） 和 Pointcut（切点） 的对应关系。代码如下：

import com.hqd.ch03.v20.aopalliance.aop.Advice;


/**
 * 维护切点和通知的映射关系接口
 */
public interface Advisor {
   
    Advice EMPTY_ADVICE = new Advice() {
   
    };

    Advice getAdvice();
}

Advisor 是个顶级接口，本身只有最通用的功能。还需要子接口去拓展其功能，例如：切点信息。额，那为什么不直接在 Advisor 接口中一起定义。嘿，因为还有个 引介增强，它是以类为维度进行增强的，并不需要切点。PointcutAdvisor 接口如下：

/**
 * 切点和通知对应关系
 */
public interface PointcutAdvisor extends Advisor {
   
    Pointcut getPointcut();
}

引介增强 也需要维护映射关系。它是的切点比较特殊，是 ClassFilter，而不是 Pointcut。接口如下：

/**
 * 引介增强映射关系
 */
public interface IntroductionAdvisor extends Advisor, IntroductionInfo {
   
    ClassFilter getClassFilter();

    /**
     * 检验接口
     *
     * @throws IllegalArgumentException
     */
    void validateInterfaces() throws IllegalArgumentException;
}

Advisor 本身的定义并不复杂，所以其实现也没有什么奇特的地方。虽然简单，可是老大言犹在耳。A君稍微思索了下：Advisor 的实现不就是存个通知和切点就完事了，还有哪里需要提取抽象类的？A君转念一想：现在框架切点匹配有一大堆实现，让用户一顿 new Advisor(new Advice(),new Pointcut()) 或者xml中配置一堆bean，再ref，好像也不是事。说好的，简单呢？说好的，开箱即用呢？切点的问题解决了。那么通知也需要这么处理吗？应该没必要，如果是通过实现接口的通知，那么压根就没法处理，总不能特地定义个子类，只是为了换个类型吧。至于 AspectJ 的通知，它另有去处。嘿嘿。那，这些不同实现的 Advisor，有什么公共点？要说公共，倒是也有一点，那就是顺序。要知道 Advisor 是单个切点和通知的管理者，通知是有顺序的，那么管理者也应该是有序的，而且这个顺序还不能乱来，得用通知的才行。这么一想，整个 Advisor 的轮廓就出来了。“果然，还是得深思熟虑呀！不然又得挨叼了。” A君感叹

思量完毕，A君先提取一个抽象类，不干别的，把排序提取出来就行了。AbstractPointcutAdvisor 代码如下：

import com.hqd.ch03.v20.aop.PointcutAdvisor;
import com.hqd.ch03.v20.aopalliance.aop.Advice;
import com.hqd.ch03.v20.core.Ordered;

public abstract class AbstractPointcutAdvisor implements PointcutAdvisor, Ordered {
   
    private Integer order;

    @Override
    public int getOrder() {
   
        if (this.order != null) {
   
            return