IOC和DI是Spring的核心功能之一，平时在使用的时候最直观的感觉就是用@Autowired代替了new，越是简单易用，越说明框架的成功。在参考了众多资料后，结合自己思考，谈谈我对IoC和DI的理解。
本篇文章主要的参考资料：
Inversion of Control Containers and the Dependency Injection pattern
用小说的形式讲解Spring（1） —— 为什么需要依赖注入
Spring 的本质系列(1) -- 依赖注入
1.IOC和DI是什么？
用一句话下个定义：
IoC，控制反转，即放弃已有的控制权，交由上层来控制。
站在Java的角度就是方法不再决定使用哪个组件来完成功能，而是交由调用者决定。
DI，依赖注入，对于IoC更为直观的描述。
简单的说，IoC，我位低权轻，只干事，不决策，还是让老大来拍板吧。
DI，IoC这个名字太宽泛，体现不出你的特点，给你个新名字吧。
2.没有IoC的日子
面向对象编程的一大特点就是对象各司其职，对象之间相互协作，共同完成功能。假设有一个信息读取功能，需要从数据库读取信息，我们可能会这么写：
public class MessageService{
public Message dealMessage(){
//直接new一个协作者DBOperator()
return new DBOperator().operate();
}
}
MessageService直接关联DBOperator，两者紧密耦合，存在以下问题：
- 不灵活
假设需求变了，该信息数据库没有，要从文件读，那么你可能会把代码改成这样：
public class MessageService{
public Message dealMessage(){
//直接new一个协作者FileOperator()
return new FileOperator().operate();
}
}
由MessageService来决定选用哪个实现类，代码在编译期即被固定，协作者Operator不能灵活切换。
- 不方便单元测试
假设现在另一个模块在做单元测试，需要用到从数据库读取的数据，就需要提供一套可用的数据库环境，能连且有需要的数据。开发环境大家都在用，难以保证时刻都可靠且正确，这将导致单元测试速度慢，不可重复，需要干预，不能独立运行。要是能模拟一个TestOperator，模拟一些数据，不用真的从数据库或文件读取，不就能解决不好测试的问题了嘛。
3.使用IoC
所以我们不让MessageService来决定使用那个实现类了，你只要专心提供服务就行了，将决定权交给调用者，这就是IoC。我们把代码改进一下：
public class MessageService{
private Operator operator;
public void setOperator(Operator operator){
this.operator = operator;
}
public Message dealMessage(){
//operator由外部传入
return this.operator.operate();
}
}
采用面向接口编程，提供一个set方法，将实现类传进来，从数据库读就传DBOperator，从文件读就传FileOperator，要测试就传TestOperator。实现解耦，灵活替换，又方便测试。
4.升级IoC
IoC的思想是有了，但总是由调用者来执行setXXX()，代码分散在"世界各地"，咱能不能把set的工作都统一到一个地方来搞呢？
整一个xml，在里面来配置所有要用的bean；解析xml，反射创建bean，在需要用的地方通过反射set bean；controller用到了service，service用到了dao，那就倒着创建bean，直接把依赖关系统统搞定；想对bean搞点事情，把bean包装一下（AOP)，设置bean在特殊状态下的行为(init/后置处理器/destory）等等。
所有这一切统统交由容器来实现，它帮我们统一创建bean，管理bean，暴露各种接口让我们随时干预bean。至此，IoC成熟落地了。
有了容器，我们可以更专注于业务逻辑的开发，容器会将我们需要的组件注射到应用程序中，我们对这一套重新起了一个更形象的名字：DI（依赖注入）。
