### 歡迎訪問我的GitHub
> 這裡分類和彙總了欣宸的全部原創(含配套原始碼)：[https://github.com/zq2599/blog_demos](https://github.com/zq2599/blog_demos)

- 文中涉及的spring版本號為4.1.8.RELEASE；

### BeanFactory介面
- 在spring容器中，BeanFactory介面是IOC容器要實現的最基礎的介面，定義了管理bean的最基本的方法，例如獲取例項、基本的判斷等，如下圖：

![image.png](https://bbs-img.huaweicloud.com/blogs/img/20220611/1654912330627822336.png)

- BeanFactory有多個子介面來進一步擴充套件bean相關的功能，以下兩個與本文有直接關係，需要關注：
- HierarchicalBeanFactory：beanFactory可以設定ParentBeanFactory，這個介面的兩個方法都是和ParentBeanFactory相關的，getParentBeanFactory方法返回ParentBeanFactory，containsLocalBean方法是相對containsBean方法而言的，containsBean方法找不到bean的時候會透過ParentBeanFactory去找，而containsLocalBean只在當前beanFactory找；
- ListableBeanFactory：主要用於獲取bean相關資訊，例如獲取所有bean名稱，查詢指定型別的所有bean等，如下圖：

![image.png](https://bbs-img.huaweicloud.com/blogs/img/20220611/1654912343955868206.png)

### ApplicationContext介面
- 關於ApplicationContext和BeanFactory的關係，看類圖即可一目瞭然：

![image.png](https://bbs-img.huaweicloud.com/blogs/img/20220611/1654912376527917988.png)

- 原來ApplicationContext繼承了HierarchicalBeanFactory和ListableBeanFactory，也就是說前面看到的介面特性都被ApplicationContext繼承下來了，另外透過類圖可以發現，ApplicationContext還繼承了諸如Environment、Resource、Message、Event
- 等相關的介面，也就是說**除了bean的管理配置相關的能力，ApplicationContext還擁有了Environment（環境）、MessageSource（國際化）、ResourceLoader（資源）、ApplicationEventPublisher（應用事件）等服務相關的介面，簡單的說ApplicationContext是以bean管理為基礎的綜合能力擴充套件，用於滿足業務對Spring綜合能力的需要；**

- 再看看ApplicationContext原始碼，除了繼承，它自身也提供了一些擴充套件的能力：

```java
public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
		MessageSource, ApplicationEventPublisher, ResourcePatternResolver {

//標識當前context例項的id，最終會透過native方法來生成：System.identityHashCode
	String getId();

//返回該context所屬的應用名稱，預設為空字串，在web應用中返回的是servlet的contextpath 
	String getApplicationName();

//返回當前context的名稱
	String getDisplayName();

//返回context第一次被載入的時間
	long getStartupDate();

//返回該context的parent
	ApplicationContext getParent();

//返回具有自動裝配能力的beanFactory，預設返回的就是初始化時例項化的beanFactory
	AutowireCapableBeanFactory getAutowireCapableBeanFactory() throws IllegalStateException;
}
```

- 小結：
1. BeanFactory是基礎，BeanFactory和它的子介面定義的API滿足了spring環境中對bean管理和配置的需求；
2. ApplicationContext是擴充套件，以BeanFactory為主線，透過繼承的方式綜合了環境、國際化、資源、事件等多條支線，自己又規定了一些擴充套件服務（如返回context的id，應用名稱等），而所有支線都以bean服務為基礎；

### 實現類解析
- 如果有個類實現了ApplicationContext介面，就必須實現上述多個介面定義的方法，這個類豈不是很複雜？我們看看AbstractApplicationContext類的原始碼，這是個基礎抽象類，常用的ClassPathXmlApplicationContext、AnnotationConfigServletWebServerApplicationContext等都繼承自AbstractApplicationContext；

- 先看看是如何實現BeanFactory介面中定義的方法的：
```java
	@Override
	public Object getBean(String name) throws BeansException {
		assertBeanFactoryActive();
		return getBeanFactory().getBean(name);
	}

@Override
	public <t> T getBean(String name, Class<t> requiredType) throws BeansException {
		assertBeanFactoryActive();
		return getBeanFactory().getBean(name, requiredType);
	}

@Override
	public <t> T getBean(Class<t> requiredType) throws BeansException {
		assertBeanFactoryActive();
		return getBeanFactory().getBean(requiredType);
	}

@Override
	public Object getBean(String name, Object... args) throws BeansException {
		assertBeanFactoryActive();
		return getBeanFactory().getBean(name, args);
	}

@Override
	public <t> T getBean(Class<t> requiredType, Object... args) throws BeansException {
		assertBeanFactoryActive();
		return getBeanFactory().getBean(requiredType, args);
	}

@Override
	public boolean containsBean(String name) {
		return getBeanFactory().containsBean(name);
	}

@Override
	public boolean isSingleton(String name) throws NoSuchBeanDefinitionException {
		assertBeanFactoryActive();
		return getBeanFactory().isSingleton(name);
	}

@Override
	public boolean isPrototype(String name) throws NoSuchBeanDefinitionException {
		assertBeanFactoryActive();
		return getBeanFactory().isPrototype(name);
	}

@Override
	public boolean isTypeMatch(String name, Class> targetType) throws NoSuchBeanDefinitionException {
		assertBeanFactoryActive();
		return getBeanFactory().isTypeMatch(name, targetType);
	}

@Override
	public Class> getType(String name) throws NoSuchBeanDefinitionException {
		assertBeanFactoryActive();
		return getBeanFactory().getType(name);
	}

@Override
	public String[] getAliases(String name) {
		return getBeanFactory().getAliases(name);
	}
```
- 看過上述程式碼後恍然大悟，原來AbstractApplicationContext並沒有自己來完成bean的管理配置，而是全部委託給了getBeanFactory()方法返回的這個例項，介面是組合，實現也是組合，這種清晰的設計是學習典範；

- 再來看看getBeanFactory()方法，解釋究竟是誰在真正的提供bean的管理配置服務，該方法的實現在AbstractApplicationContext的子類AbstractRefreshableApplicationContext中，程式碼很簡單，返回了成員變數beanFactory：
```java
public final ConfigurableListableBeanFactory getBeanFactory() {
		synchronized (this.beanFactoryMonitor) {
			if (this.beanFactory == null) {
				throw new IllegalStateException("BeanFactory not initialized or already closed - " +
						"call 'refresh' before accessing beans via the ApplicationContext");
			}
			return this.beanFactory;
		}
	}
```
- 該成員變數在refreshBeanFactory方法中例項化，而refreshBeanFactory方法又是在spring容器初始化的時候呼叫的，所以容器初始化之後，AbstractApplicationContext就具備了bean管理配置的能力；

### 擴充套件思考
- 看了AbstractApplicationContext類中beanFactory相關的程式碼，我就猜想：**莫非Message支線也是這個套路，委託給Message服務相關的例項來完成？**看程式碼吧：
```java
	@Override
	public String getMessage(String code, Object args[], String defaultMessage, Locale locale) {
		return getMessageSource().getMessage(code, args, defaultMessage, locale);
	}

@Override
	public String getMessage(String code, Object args[], Locale locale) throws NoSuchMessageException {
		return getMessageSource().getMessage(code, args, locale);
	}

@Override
	public String getMessage(MessageSourceResolvable resolvable, Locale locale) throws NoSuchMessageException {
		return getMessageSource().getMessage(resolvable, locale);
	}
```
- 如上所示，果然如此，Message相關的介面實現，都是getMessageSource()方法返回的例項在承擔，getMessageSource()方法返回的是成員變數messageSource，該成員變數也是在spring容器初始化的時候，呼叫initMessageSource方法生成的；

- 至此，透過檢視原始碼，我們對spring的BeanFactory和ApplicationContext有了更清晰的認識，又經歷了一次結合類圖分析原始碼的實踐，在您學習spring的路上，希望本文能助您一臂之力，一起學習、共同進步；

### 歡迎關注ITpub：程式設計師欣宸
> [學習路上，你不孤單，欣宸原創一路相伴...](http://blog.itpub.net/70017844/)</t></t></t></t></t></t>

spring的BeanFactory和ApplicationContext

相關文章