spring深入发掘-IOC容器解读系列-BeanFactory

API和SPI

提到API，我们所有人都熟悉，但是提到SPI，相信就有人挠头了。要了解Spring的BF和AC体系，区分这两个概念比较重要。

API是"应用编程接口"，Application Programming Interface；SPI是"服务提供者接口"，Service Provider Interface。API是面向使用者而言的接口，使用者调用接口来完成需求；SPI是面向实现者的接口，实现者通过实现接口来完成需求。典型的例子，J2EE中的分布式事务规范是包括两套的，JTA和JTS，前者是面向应用程序开发者的，我们接触的比较多，而后者是面向应用服务器或者其他事务管理器实现者的，两套规范协同工作，完成了分布式事务工作。

API和SPI有时候可以是同一个接口，比如JDBC的Connection接口，对我们开发者而言，它是我们访问数据库的API，但是对于Oracle JDBC驱动开发者而言，它是一个SPI。一个接口是API还是SPI，取决于是谁在使用它，谁会使用它。

BeanFactory

BeanFactoriy是一个API，这一点在它的注释中说的很清楚。那么作为一个"Bean工厂"的使用者（而不是实现者），你期望它提供什么功能呢？至于你想不想，反正我想让它提供创建Bean的功能，就是我给他一个名字，它给我这个Bean的实例，围绕这个核心功能，还可以有一些变体。BF现在的实现，正是完成了这个要求，对于BF如何创建Bean这样的问题，是SPI接口需要考虑的事情。

有人说如果是这样，那么ListableBeanFactory也符合API的特征--没有创建Bean的方法，只有读取Bean信息的方法，并且提供了枚举BF中Bean的功能（而不是像BF那样根据名字一个个获取），为什么要把这些职责从BF中分离出来单独成为一个接口呢？原因很简单，还是那句"越本质，越简单"。事实上并不是所有的BF都能在启动的时候创建所有的Bean实例，于是就无法去枚举它们，比如直接继承自BF的SimpleJndiBeanFactory类。

SimpleJndiBeanFactory

我们很少在工作中用到SimpleJndiBeanFactory类，但这个类的存在却可以让我们较全面地理解BF。

这个类的作用，是根据传入的JNDI名字获取到对应的绑定对象，这一点使它完全符合BF的定义。它跟我们常用的BF不同之处在于，我们使用的BF都是自己创建Bean实例，而SimpleJndiBeanFactory不是自己创建Bean实例，JNDI Object都是由各自的资源管理器创建的，SimpleJndiBeanFactory只是做了一层代理，让使用者可以使用BF的标准接口来访问JNDI Object。

SimpleJndiBeanFactory的存在告诉我们，创建Bean并不是BF接口约束的职责，BF只是一个API，为它的使用者提供获取Bean实例的标准接口。

猜想和后续

Spring的IOC体系中既有BF这样的API，也有AutowireCapableBeanFactory这样的SPI，我想最初的设计者定义这样一套体系，是想像分布式事务规范那样，为两个不同的开发者群体提供一套标准接口，BF实现者用AutowireCapableBeanFactory这样的SPI创建BF，BF使用者用BF和ListableBeanFactory这样的标准接口使用BF而不必关心Bean被创建的细节。

这里介绍了BF的设计原理，接下来，我们看看BF的三个一代弟子：AutowireCapableBeanFactory，HierarchicalBeanFactory和ListableBeanFactory。