Spring----IOC的理论推导

前言

IOC不是一种框架，也不是一段代码，而是一种设计思想。我们需要通过思维的转变去理解这个过程。

1. IOC理论推导

在还没有Spring框架之前，用户需求会影响我们原来的代码，我们需要根据用户的需求修改原来的代码，如果代码十分多。修改一次成本价十分昂贵。
如：这段代码修改的主动权在程序员手上 （若用户想使用一个新的实现方式，我们程序员需要修改业务层的代码）

private UserDao  userDao = new UserDaoImpl();

若我们使用一个Set方法完成一个接口的实现 (这时用户向使用哪个实现方式传入即可，而不需要我们程序员去修改业务层的代码)

 private UserDao userDao;
//利用set进行动态实现值的注入
public void setUserDao(UserDao userDao) {
    this.userDao = userDao;
}

• 之前，程序是主动创建对象，程序控制权在程序员手上
• 使用了set注入后，程序不再具备主动性，而是变成了变动的接收对象

这种思想，从本质上解决了问题，我们程序员不用再去管理对象的创建，系统的耦合性大大降低，可以更加专注在业务的实现上，这就是IOC的原型。

2. IOC本质

1. IOC又叫控制反转，是一种设计思想。DI(依赖注入)是实现IOC的一种方式。也有人认为DI只是IOC的一种说法，没有IOC的程序中，我们使用面向对象编程，对象的创建与对象间的依赖关系完全编码在程序中，对象的创建完全由程序自己控制(即我们程序员本身)，控制反转后将对象的创建转移给第三方。控制反转可以理解为获得依赖对象的方式反转了。
2. 采用XML方式配置 Bean的时候，Bean的定义信息是和实现分离的，而采用注解的方式可以把两者合为一体，Bean的定义信息直接以注解形式定义在实体类中，从而达到零配置的目的。
3. 控制反转是一种描述 (XML或注解) ，并通过第三方生成或获取特定对象的方式，在Spring中实现 控制反转的是IOC容器，器实现方式是依赖注入 (Dependency Injection DI)