Spring IOC

在Spring揭秘一书中，谈到IOC的时候谈到让别人为你服务，而不是你需要服务的时候去打电话叫人前来。我们需要的是服务，如果能实时准备好让我用你的服务就再好不过。

不管是直接打造家具（通过new构造对象），还是去家具广场买家具（或许是通过ServiceLocator①解决直接的依赖耦合），有一个共同点需要我们关注，那就是，我们都是自己主动地去获取依赖的对象！
可是回头想想，我们自己每次用到什么依赖对象都要主动地去获取，这是否真的必要？我们最终所要做的，其实就是直接调用依赖对象所提供的某项服务而已。只要用到这个依赖对象的时候，它能够准备就绪，我们完全可以不管这个对象是自己找来的还是别人送过来的。对于FXNewsProvider来说，那就是getAndPersistNews()方法调用newsListener的相应方法时， newsListener能够准备就绪就可以了。如果有人能够在我们需要时将某个依赖对象送过来，为什么还要大费周折地自己去折腾？
实际上， IoC就是为了帮助我们避免之前的“大费周折”，而提供了更加轻松简洁的方式。它的反转，就反转在让你从原来的事必躬亲，转变为现在的享受服务。你想啊，原来还得鞍马劳顿，什么东西都得自己去拿。现在是用什么，让别人直接送过来就成。所以，简单点儿说， IoC的理念就是，
让别人为你服务！

通常情况下，被注入对象会直接依赖于被依赖对象。但是， 在IoC的场景中，二者之间通过IoC Service
Provider来打交道，所有的被注入对象和依赖对象现在由IoC Service Provider统一管理。被注入对象需要
什么，直接跟IoC Service Provider招呼一声，后者就会把相应的被依赖对象注入到被注入对象中，从而
达到IoC Service Provider为被注入对象服务的目的。 IoC Service Provider在这里就是通常的IoC容器所充
当的角色。从被注入对象的角度看，与之前直接寻求依赖对象相比，依赖对象的取得方式发生了反转，
控制也从被注入对象转到了IoC Service Provider那里。

采用外部配置文件时， Spring的IoC容器有一个统一的处理方式。通常情况下，需要根据不同的外
部配置文件格式，给出相应的BeanDefinitionReader实现类，由BeanDefinitionReader的相应实
现类负责将相应的配置文件内容读取并映射到BeanDefinition，然后将映射后的BeanDefinition注
册到一个BeanDefinitionRegistry，之后， BeanDefinitionRegistry即完成Bean的注册和加载。
当然，大部分工作，包括解析文件格式、装配BeanDefinition之类的工作，都是由BeanDefinitionReader的相应实现类来做的， BeanDefinitionRegistry只不过负责保管而已。整个过程类似于如下
代码：

DefaultListableBeanFactory>;
BeanDefinitionReader beanDefinitionReader = new BeanDefinitionReaderImpl(beanRegistry);
beanDefinitionReader.loadBeanDefinitions("配置文件路径");
// 现在我们就取得了一个可用的BeanDefinitionRegistry实例

BeanFactory可以分层次（通过实现HierarchicalBeanFactory接口），容器A在初始
化的时候，可以首先加载容器B中的所有对象定义，然后再加载自身的对象定义，这样，容器
B就成为了容器A的父容器，容器A可以引用容器B中的所有对象定义：
BeanFactory parentContainer = new XmlBeanFactory(new ClassPathResource("父容器配置文件路
径"));
BeanFactory childContainer = new XmlBeanFactory(new ClassPathResource("子容器配置文件路
径"),parentContainer);
childContainer中定义的对象，如果通过parent指定依赖，则只能引用parentContainer中
的对象定义。