第六十二章 Spring之假如让你来写Boot——番外篇：重构BeanFactory-CSDN博客

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

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

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

书接上回，在上篇 第六十章 Spring之假如让你来写Boot——自动装配篇 中，A君昨天已经完成了自动装配这一大功能，自动装配可以说是 Boot 的半壁江山，剩下的东西也不多了。。。

尝试动手写IOC容器

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

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

前情提要：A君已经完成了自动装配这一大功能。。。

重构BeanFactory

在之前的版本中，A君为了简单，没有给BeanFactory加上太多的东西，基本上保持着能用就行了态度，实现不行才加上点东西。到了现在，又是注解，又这那的。还是只有那些功能，实在有点捉襟见肘了，不得已，A君只能重新考量下BeanFactory

`BeanFactory`

按照 Spring 的设计理念，每个接口往往相互独立，尤其是顶级接口，功能是最通用的。也就是所谓的 接口单一原则 嘛。BeanFactory同样也不例外，Spring 同样让他保留最通用的功能，像是什么根据名称获取Bean、根据类型获取Bean、获取别名之类的功能都归到BeanFactory中。代码如下：

在这里插入图片描述

`HierarchicalBeanFactory`

不知怎么滴，现在的框架都喜欢设计父子结构。JVM 有双亲委派、Tomcat 各个组件之间也存在层级关系。Spring 呢，也不例外，同样存在着层级结构。记得老早之前，那会儿还没有 SpringBoot，A君很苦逼的用着 SSM时，遇到过一个问题：父子容器。当初可把 A君折腾坏了，现在回头看，其实问题也很简单，无非就是 Spring 和 SpringMVC 形成了两个容器，而 Spring 的访问机制是从当前容器逐层往上找，也就是意味着父容器不知道子容器中的注册的Bean，从而形成父子容器的问题。而造成这一切的‘罪魁祸首’，就是——HierarchicalBeanFactory。要想形成层级结构，要么当前对象包含子容器，要么就是包含父容器。联想到 Spring 先子后父查找Bean的方式，那么自然就是保存父容器的引用了。代码如下：

在这里插入图片描述

`ConfigurableBeanFactory`

在前面的章节中，A君总是时不时提到什么编程式，声明式。相信大伙儿耳朵都快听出茧子来了。不过，这里 A君还是要啰嗦了下。简单的说：编程式就是可以通过写代码实现，而声明式则是通过配置来实现。这么说来，声明式似乎完爆编程式，正经人谁去写代码实现功能。话是这样没错，但是也不排除有些情况下，配置比代码更加麻烦，而且写代码也有写代码的好处，那就是灵活。废了这么多话，一句话概括，就是既要还要。主体还是用声明式，但是编程式也保留，用户自己决定怎么用。啥声明式、编程式的，把人整的一愣一愣的。作为开发，这关心代码怎么写。说穿了，也没啥，就是一堆set方法。ConfigurableBeanFactory代码如下：

在这里插入图片描述

`AbstractBeanFactory`

已经定义了这么多个接口，也到了提取抽象类的时候了。这里就不在展开说明，怎么创建Bean对象，在前面相关的章节已经有详细说明了，Spring 本身的创建流程也差不多，只是提供了更多的功能。主体内容大差不差

在这里插入图片描述

`AutowireCapableBeanFactory`

上面提到的功能基本已经满足常见的场景，只是少了一捏捏拓展，试想一下，有个Bean不只是创建出来那么简单，还是对对其进行初始化，用户不想，或者说是不能构造器初始化，这时候要怎么办？又比如用户想在Bean创建前后进行一些处理，这时候又要怎么办？一个优秀的框架既要满足大部分场景，又得留下足够的拓展，以便用户进行定制化开发。当然，这些功能会提供另外的接口，不会由AutowireCapableBeanFactory来处理，AutowireCapableBeanFactory要处理的事情是把这些方法规定出来，告诉实现者，有对应的初始化方法、前后置事件需要执行。这样设计初衷是为了增强灵活性，允许开发者在特定场景下对现有的非 Spring 管理的对象进行依赖注入、初始化以及生命周期管理。这对于需要将第三方组件或已有实例集成到 Spring 容器中的情况尤为有用。知道了AutowireCapableBeanFactory作用，再来看下对应的代码吧，如下：

在这里插入图片描述

`AbstractAutowireCapableBeanFactory`

接着，还是老样子，可以提取抽象类了，这个抽象类以前没见过，不过看接口也能大致猜出来就是些自动设置属性的活，来看看代码验证下吧。

在这里插入图片描述

`ListableBeanFactory`

除了上述说到的功能，还缺少一个很重要的功能。那就是可列举的。啥？太术语化了？用人话说：就是可以获取容器中所有的信息，这返回值要么就是数组，要么就是链表。肯定是个集合，可以遍历，故而称为可列举的。这个功能重要性应该不言而喻，很多时候需要根据一些条件去容器中查找对应的Bean，像包含某些注解、是否是某个类的子类等。代码如下：

在这里插入图片描述