参与者：应用程序和spring
正向：现在的程序方向，A对象要使用B对象，现在是A里面直接创建B的实例，然后调用。
publc class A{
void t1(){
new B().t2();
}
}
public class B{
void t2();
简而言之，就是程序需要什么。就由程序主动去获取需要的资源，这个方向就是正向。
容器是用来创建和装配对象，并管理对象生命周期的。对于应用程序而言，就是被动实例化和被动接受依赖了。
装配：
在spring容器内拼凑bean叫作装配。装配bean的时候，你是在告诉容器，
需要哪些bean，以及容器如何使用依赖注入将它们配合在一起。
IOC/DI思想：
1把程序之间的依赖关系去掉。
2把程序对象设置到IOC/DI容器的配置中，作为Bean
3 由IOC和DI容器来管理Bean的创建，实例化。
4 由IOC/DI容器把Bean之间的关系注入到需要这些关系的对象里面。
简而言之就是对象之间的依赖，全部去掉，然后由IOC/DI容器管理对象和对象之间的依赖关系。
功能：实现了对象之间的松散耦。
1谁控制谁？
IOC/DI容器控制应用程序
2控制什么
a控制对象本身的创建和实例化和装配
b控制对象之间的依赖关系
3为何叫反转？
因为应用程序不能主动的获取外部资源 ，而是被动等待IOC容器给他注入他所需要的资源。所以称为反转。
4：哪些方面反转了？
（1）创建对象的地方，spring创建
（2）程序获得资源（比如依赖的其他对象，也就是依赖关系）的方式反了。
5 为何需要反转？
（1）引入了容器过后，整个体系更为松散，而且管理更有序。
（2）类之间的依赖关系真正实现了松散耦合，使得开发测试修改等变得容易。
IOC/DI并没有帮我们实现任何的业务功能，原本该有应用实现的功能，还是有应用自身完成。
7：什么是依赖
依赖（动词）于注入依赖（名词）关系
8 谁依赖于谁？
应用程序依赖于IOD/DI容器。
9为什么需要依赖？
因为反转了过后，应用程序需要的资源都在容器里，所以要依赖容器。
10 依赖什么东西？
应用程序依赖于IOD/DI容器。依赖IOC/DI容器为它注入所需要的资源。（比如：依赖关系）
简写就是：依赖于注入依赖（名词）关系。应用程序依赖IOC注入依赖关系。
11 谁注入谁
IOC/DI容器 注入与应用程序
12注入什么东西？
注入应用程序需要的外部资源，比如依赖关系，常量值什么的
13 为何注入？
因为程序要正常运行，需要这些资源。
14 依赖注入和控制反转是同一个概念吗？
不是同一个概念
其实描述的是同一件事，但是是从不同的角度在说。
控制反转：从IOC/DI的容器来说。容器反过来控制应用程序
依赖注入：是应用程序的角度来说。
15
控制反转的描述：IOC/DI容器反过来控制应用程序，控制应用程序所需要的外部资源，比如依赖关系
依赖注入的描述：应用程序依赖IOC/DI容器，依赖它（容器）注入所需要的外部资源。
16 IOC和DI 是什么？
IOC：是一种使用IOC/DI容器反过来控制应用程序，控制应用程序所需要的外部资源，这是一种程序开发思想
ID：应用程序依赖容器来注入所需的外部资源，是一种开发思想
17能做什么
松散对象的耦合。
使用spring，spring里有实现好的IOC/DI的容器，这样就不用自己去实现
18 怎么做？
可以自己实现，
19 用在什么地方？
凡是程序里面需要使用到外部资源的情况，都可以考虑使用IOC/DI容器
比方说 工厂类，现在就不需要啦。
20强调一下外部资源的概念
对一个类来讲，所谓外部资源，就是指在自己类的内部，不能得到或实现的东西，比方说在类里读取一个配置文件
，那么这个配置文件就相当于这个类的外部资源。
又比如：A类里面要调用B类的方法，需要在A类获取B类的对象，那么对于A来讲，B就是外部资源。
21 什么是IOC容器
就是实习IOC思想，并提供对象创建，对象装配以及对象生命周期管理的软件就是IOC容器。
IOC理解：
1 应用程序无需主动new对象，而是描述对象应该如何被创建，IOC容器帮你创建，即被动实例化
2 应用程序不需要主动装配对象之间的关系，而是描述需要哪个服务，IOC容器会帮你装配，被动接受装配。
3 主动变被动。如：别给我们打电话，我们会打给你。
4 应用程序不知道依赖的具体实现，只知道需要提供某类的服务对象（面向接口）：并松散耦合，一个对象
应当对其他对象尽可能少的了解，不和陌生人说话。
5 减少类与类之间依赖的设计原则
主动变被动：
以前是应用程序是主动，现在变成了被动。但是他要告诉IOC容器需要什么资源，然后容器讲资源注入程序。
应用程序永远是被动的。
1 ioc和DI等于工厂吗？
不等，思想源于工厂，但是高于工厂，IOC/DI的思想是 DI+容器
2跟以前的方式有什么不一样
反转。去掉了工厂
使用IOC/DI容器开发需要改变的思路：
1应用程序不主动创建对象，但是要描述创建他们的方式。
2在程序代码中不直接进行服务的装配，但是要描述哪一个组件需要那一项服务，由容器负责将这些装配在一起。
也就是说：所有的组件都是被动的，组件初始化和装配都由容器负责，应用程序知识在获取相应的组建后，实现
影响的功能即可。
重点：
IOC/DI 是思想，不是纯实现技术。IOD是框架共性，只是控制权转转移，转移到框架，所以不能因为实现了IOC就叫IOC容器。
除了实现IOC外，还要具有DI的功能才叫IOC容器，因为容器除了负责创建并装配组件关系，还需要管理组件的
生命周期。