Spring IOC - start

Spring 使用已经有些年头了，但始终没有静下心来整理 Spring，关于 Spring 各种实现方式也都是大而概之的了解，也没有深入的研究。今天终于鼓起勇气来整理他了。

 

万事开头难，从哪里开始呢，那就从常用的 Factory 开始吧。

在日常的使用中，比较少的直接使用 BeanFactory，常用是 ApplicationContext 接口。下面我们就以FileSystemXmlApplicationContext 为例，开始梳理 Spring 中的依赖注入的知识。

 

首先看看 FileSystemXmlApplicationContext 实现了那些接口、继承了那些基类：

上图可以说明 FileSystemXmlApplicationContext 是一个具有完整功能的 BeanFactory，直接可以被客户使用。可以把它分为两部分接口的体现，一方面是 BeanFactory ，另一方面是 ResourceLoader 。前者使其具体 Factory 的相关功能，后者使其具体资源加载的功能。我们在日常中常用的 ApplicationConext 接口是继承与 BeanFactory 的，FileSystemXmlApplicationContext 也实现了这个接口。

 

下面我们分析一下其构造器源码：

// 默认构造器
public FileSystemXmlApplicationContext() {
}

// 指定了父容器的构造器
public FileSystemXmlApplicationContext(ApplicationContext parent) {
	super(parent);
}

// 指定单个的配置文件位置构造器
public FileSystemXmlApplicationContext(String configLocation) throws BeansException {
	this(new String[] {configLocation}, true, null);
}

// 指定多个配置文件位置构造器，默认需要刷新容器
public FileSystemXmlApplicationContext(String... configLocations) throws BeansException {
	this(configLocations, true, null);
}

// 指定了配置文件和父容器的构造器，默认需要刷新容器
public FileSystemXmlApplicationContext(String[] configLocations, ApplicationContext parent) throws BeansException {
	this(configLocations, true, parent);
}

// 指定了配置文件位置以及是否需要刷新的构造器
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh) throws BeansException {
	this(configLocations, refresh, null);
}

// 核心构造器，设置了Bean配置文件位置、是否需要刷新容器、父容器的构造器
// 如果配置了需刷新容器，则调用刷新接口。
// refresh方法是由AbstractApplicationContext提供，后面的笔记中应该相信说明这方法（后续附上链接）
public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
		throws BeansException {

	super(parent);
	setConfigLocations(configLocations);
	if (refresh) {
		refresh();
	}
}

 FileSystemXmlApplicationContext 定义是很简单，他其中关于 Bean 的资源查找、解析、注册都有其父类完成。

 

Spring 中关于资源的查找是很大一部分内容，这部分功能大部分是依赖 DefaultResourceLoader 的实现，下次主要说明 Spring 是如何加载资源文件的。