Spring5 02 IOC理论推导

2.1 IOC理论

---

IOC 控制反转 （Inversion of Control），是一种 设计思想，DI（依赖注入）只是 实现 IOC 的一种方法。也有人 认为 DI 只是 IOC的另一种说法。 没有 IOC 的程序，我们 在使用 面向对象编程语言的时候，对象的创建与对象间的依赖关系 是完全硬编码在程序中的，即比较死板，不灵活。这个时候 对象的创建完全是由程序自己本身控制的。而 IOC 就是 将 对象的创建 交给第三方去决策，再进一步的处理。个人认为所谓的控制反转就是：获取以来 对象的 方式 进行了反转！

在图中 IOC 是类似于一个中间件的存在，将 耦合性的四个对象，进行了解耦。

IOC 是 Spring 框架的 核心内容，所以必须要讲解。它使用了 多种方式 完美的实现了 IOC，可以 使用 XML 文件去进行配置，也可以使用 注解去实现。当然，新版本的 Spring 可以零配置 实现 IOC 这绝对是一个重大突破，因为 Java 主流框架 之所以难学 就在于 大量的约定和配置。如果可以 零配置 实现某些功能，那才是 真正的便捷！！！

Spring Bean：在 Spring 中，构成应用程序主干并由Spring IoC容器管理的对象称为bean。bean是一个由Spring IoC容器实例化、组装和管理的对象。

也就是说 如果 Spring 主要 用的 都是 控制反转的话，那么 它就得 创建 多个 Bean 对象，来 组成我们的应用程序。

比如 采用 上图 的 XML 方式配置。去创建 Bean 的时候，Bean 的定义信息就会和实现 分离。而采用 注解的方式 就可以把两者 合为一体。Bean 的定义信息直接以 注解的形式定义在 实现类中，从而达到了 零配置的目的。

在 Spring 的 IOC 容器中。IOC 控制反转，就是 通过 一种描述（XML 或 注解）进一步 通过 第三方 去生产或获取特定对象的一种方式。其实 实现的 方法 还是 依赖注入 DI。

---

2.2 IOC理论推导

正常的步骤：

1. UserDao接口（数据库操作）
2. UserDaoImpl 实现类（数据库操作）
3. UserService 业务接口（利用Dao层去实现业务）
4. UserServiceImpl 业务实现

然后有一个最大的问题，而且这个问题想解决的话，十分的简单和容易。

业务层调用Dao层的时候，需要自己手动去更改代码。描述这个问题听起来好像无伤大雅，但这只是这种问题展现方式的一种而已。即 很多时候略加改变就要 手动的改写代码，改写的量多与少，完全 看 情况。也就是说代价 是 无法估计的。

• 那么 怎么解决呢？

答：IOC 理论就被提出了，根据 2.1 上面说的概念，可以精炼一下。简单来说的话，就是 我们 对外 开放一个接口，然后 让外部 提供给我们参数，根据参数 去决定 选择权，和判断 代码应该 如何去变动，甚至可以 提前 预判好 怎样去变动。

---

2.2 使用 IOC理论的 前后对比

• 使用 IOC 理论 改良前
  
  现在 多加了一个 UserDao 的实现类，而我们 有时候需要用到它。
  
  
  我们说这个情况，其实 就是 我们 在 2.1 的时候 说的那个问题。即 我们的 决定权，选择权 不在于 用户或业务层，而是 在于 程序代码底层的本身。这绝对是一个大问题。这使得程序 非常的死板，改动代价 很大。

• 使用 IOC理论 改良后

IOC 理论最简单的实现方式：对外开放一个接口，让外面的调用者，提供一些参数，真正决定结果。

package top.muquanyu.service;
import top.muquanyu.dao.UserDao;
import top.muquanyu.dao.UserDaoImpl;
import top.muquanyu.dao.UserMySQLImpl;
public class UserServiceImpl implements UserService{
    private static UserDao userDao = new UserDaoImpl();
    public UserServiceImpl(UserDao userDao){
        this.userDao = userDao;
    }
    public void setUserDao(UserDao userDao){
        this.userDao = userDao;
    }
    @Override
    public void printUser() {
        System.out.println(userDao.getUser());
    }
}

切记：IOC 就是一个 理论，而具体你怎么去实现这个理论，因人而异。没有人去限制你 怎么去实现 这个理论！！

总结：

• 之前，程序是 主动创建对象，控制权在程序猿手中，或者说在程序手中。
• 使用set注入后，程序不再具有强势的主动性，而是变成了被动接受的对象。

这种思想，从本质上解决了这个看似简单实则严重的问题。我们程序猿不再需要去管理对象的创建了。系统的耦合性大大降低了。可以更加专注于业务的实现了。当然 这还不算是 真正 牛逼的 IOC 实现和展示。在我们 学习 Spring 的时候，你会见到 很多 IOC 理论的 实现和使用。