【Spring】Spring IOC理论推导

Spring IOC理论推导:

IOC理论推导：

以前方式(使用IOC之前)：
1.UserDao(接口)：

2：UserDaoImpl(实现类)：

3：UserService(业务接口)：

4：UserServiceImpl(业务实现类)：

5：MyTest(测试类)：

如果此时我们还需要一个需求。那么首先需要编写一个新的用户实现类：UserDaoMsqlImpl

然后修改UserServiceImpl(服务实现类)中的对象：


如果此时又来一个新需求(UserDaoOracleImpl)

那么我们又要去UserServiceImple中手动的修改对象：


如果此时我们又要使用SqlServer，又需要去UserServiceImpl里面修改相应的实现(UserService userService = new UserSqlserverImpl()),假设我们的这种需求非常大，这种方式根本不适用，甚至反人类。每次变动，都需要修改大量代码，这种设计的耦合性太高，牵一发而动全身。
在以上这种业务中，用户的需求可能会影响我们原来的代码，我们需要根据用户的需求取修改原来的代码！如果程序代码量十分大，修改一次的成本代价十分昂贵！
IOC方式：
为了避免每当出现新需求，我们都要去手动修改对象。我们可以在UserServiceImpl(服务实现类)设置一个接口(之前都是通过new来创建对象)。然后通过set方法动态实现值的注入！

此时程序的主动权在用户手上，用户想调用哪个只需在setUserDao中放入所需的需求(Oracle就new UserDaoOracleImp).
![在这里插入图片描述](https://img-blog.csdnimg.cn/20200103162703791.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x4MTU2OTE4MjE5ODQ=,size_16,color_FFFFFF,t_70
之前程序是主动创建对象！控制权在程序员手上！
使用了set注入后，程序不在具有主动性。而是变成了被动的接受对象！
这种思想从本质上解决了问题，我们程序员不用再去管理对象的创建。系统的耦合性大大降低，可以更加专注的在业务的实现上！这是IOC的原型！

IOC本质：

控制反转IOC(Inversion of Control),是一种设计思想，DI(依赖注入)是实现IOC的一种方法，也有人认为DI只是IOC的另一种说法，在IOC的程序中，我们使用面向对象编程，对象的创建与对象之间的依赖关系完全硬编码在程序中，对象的创建由程序自己控制；控制反转后将对象的创建转移给第三方，个人认为所谓控制反转就是：获得依赖对象的方式反转了。
控制反转是一种通过描述(XML或注解)并通过第三方生产或获取特定对象的方式。在Spring中实现控制反转的是IOC容器，其实现方法是依赖注入。
IOC是Spring框架的核心内容，使用多种方式完美的实现了IOC，可以使用XML配置，也可以使用注解，新版本的Spring也可以实现零配置(自动装配)实现IOC。
采用XML方式配置bean的时候，bean的定义信息是和实现分离的，而采用注解的方式可以把两者合为一体，bean的定义信息直接以注解的方式定义在实现类中，从而达到了零配置的目的。
spring容器在初始化的时候先读取配置文件，根据配置文件或元数据创建与组织对象存入容器中，程序使用时再从IOC容器中取出需要的对象。