Mini-Spring 实战：初探 Bean 工厂的继承体系

Mini-Spring 实战：初探 Bean 工厂的继承体系

今天开始记录 mini-spring 的实现过程。要构建一个 Spring 容器，第一道关卡就是理清其底层 Bean 工厂（BeanFactory）的继承与实现关系。

1. 职能拆解：三大核心行为接口

Spring 并没有将所有功能塞进一个类，而是通过接口定义了三个核心行为，实现了单一职责原则：

• BeanDefinitionRegistry：负责 Bean 定义的“户籍管理”，定义了注册行为：registerBeanDefinition()。
• SingletonBeanRegistry：负责单例对象的“物料缓存”，定义了获取单例的行为：getSingleton()。
• BeanFactory：作为统一的对外暴露窗口，定义了获取 Bean 实例的最基本行为：getBean()。

2. 阶梯式实现：从抽象到具体

通过层层继承，Spring 将复杂的 Bean 生命周期管理拆解到了不同的抽象层中：

• DefaultSingletonBeanRegistry
  • 职责：基础仓库。实现了单例缓存逻辑，直接通过 Map<String, Object> 进行存取。
• AbstractBeanFactory (模板方法模式)
  • 职责：流程控制。它实现了 getBean() 的骨架逻辑：先查缓存，若无缓存则获取 Bean 定义并触发创建流程。
  • 注意：它并不关心“如何创建”，将具体实现留给了子类。
• AbstractAutowireCapableBeanFactory
  • 职责：真正的执行者。实现了 Bean 的实例化逻辑（如 Class.newInstance()），并在对象创建完成后自动将其注入单例缓存。
• DefaultListableBeanFactory
  • 职责：全能集成者。它是整个继承链的终点，具体实现了 BeanDefinitionRegistry 接口（利用 Map<String, BeanDefinition> 维护定义），成为了一个功能完备的工厂实现。

3. 为什么这样设计？（架构收益）

这种高度解耦的继承体系带来了极佳的扩展性：

1. 灵活定义实例化逻辑：如果想修改 Bean 的实例化方式（例如引入工厂方法或 AOP 代理），只需在 AbstractAutowireCapableBeanFactory 层级进行扩展，而不必触动核心流程。
2. 关注点分离：开发者只需关注具体的行为实现（如注册定义、获取对象），而复杂的调用链路已被抽象类封装完毕。