RawChen. | 对IOC控制反转的理解?

对IOC控制反转的理解? 原创

2020-06-14 08:19 1471

#是什么？
:smile:IOC全称是 `Inversion of Control`控制反转。按照字面意思理解，将控制反转过来，这里的控制指的是什么？为什么要进行反转，ioc可以解决什么问题？要回答这些问题，我们需要先了解一下IOC为什么会产生。
#怎么来的？
Java是一门面向对象的语言，我们的应用程序通过一个个对象之间的**相互关联**和作用来完成功能，就像手表里的机械结构。每一个齿轮代表一个对象，对象之间彼此紧密咬合形成一个系统，这样的系统对象之间的**耦合度**非常高，所谓的耦合度就是关系的依赖程度，高耦合度带来的问题显而易见，只要有一个齿轮发生故障，其它齿轮也无法工作，进而整个系统都无法正常工作，这种牵一发而动全身情况如何才能改善呢？

![][1]

再来一个Service层实际的例子：
```Java
public class UserServiceImpl {
    private UserDao userDao = new UserDaoImpl();
    private UserDao userDao = (UserDao)BeanFactory.getBean("userDao");

public List<User> getAllUser(){
        return userDao.getAllUser();
    }
}
```

一个是**独立控制**通过**new**一个UserDao实现类来完成，一个是**Bean工厂**通过全限定类名找到Bean对象并创建多例对象，**无法自主控制**。第二者把控制权交给了Bean工厂来创建对象，带来的好处就是降低程序间的依赖关系，也叫削减计算机的耦合。

#改善方法？
上面机械齿轮的例子可以通过一个中间齿轮的方式来解决，也就是后面的**中间IOC容器**。所有的齿轮都交由中间这个齿轮管理，试着把中间这个齿轮拿掉我们可以看到这两个齿轮之间彼此毫无关系，即使一个齿轮出了故障，也不会影响到其它齿轮。
中间这个齿轮就好比ioc容器，其它齿轮就是对象，可以看出引入了ioc容器，对象之间的耦合度降低了。当我们修改一个对象的时候不需要去考虑其它对象，因为它不会对其它对象造成影响。
#ioc的原理？
这里说到的ioc容器到底是个什么东东，又是什么让它具有如此神奇的力量？

先来看一下没有ioc容器的时候，对象A依赖对象B，A在运行到某一时刻的时候会去创建B的对象，在这里A具有主动权，它控制了对象B的创建。

引入ioc以后对象A和对象B之间没有了直接联系，当A运行的时候由ioc容器创建B对象在适当的时候注入到A中，在这里，控制权由A对象转移到了ioc容器。这也就是控制反转名称的由来。

基于上述UserDao的例子我们可以通过**反射**来**解耦**，反射可以根据类的全限定名在程序运行时创建对象，可以这样做，将类的全限定名配置在xml文件中，在程序运行时通过反射读取该类的全限定名，动态的创建对象，赋值给userDao接口userDaoImpl。这样做后UserServiceImpl和UserDaoImpl之间没有了直接的关系，当我们需要替换UserDaoImpl对象的时候只需要在配置文件中去修改类的全限定名就可以了，非常的灵活方便，ioc容器的实现就是这个原理。

IOC容器可以自动的帮我们完成以上一系列操作，我们需要做的就是通过配置文件告诉ioc需要创建哪个类以及类和类之间的关系。

#控制反转和依赖注入
在这里需要提到一个概念**依赖注入**，很多初学者搞不清楚控制反转和依赖注入之间的关系，其实他们是对同一事物的不同角度的描述。
**控制反转是一种设计思想**而**依赖注入是这种思想的具体实现**

具体说控制反转就是将创建userDaoImpl对象的控制权反转过来由UserServiceImpl交给了ioc容器，强调的是一种能力和思想，ioc容器具有了控制权。

依赖注入就是ioc容器将UserServiceImpl所依赖的对象userDaoImpl，注入给UserServiceImpl，强调的是一个**过程和实现**。

IOC很好的体现了面向对象设计法则之一—— 好莱坞法则：“别找我们，我们找你”。

#优缺点

1. 软件系统中由于引入了第三方IOC容器，生成对象的步骤变得有些复杂，本来是两者之间的事情，又凭空多出一道手续，所以，我们在刚开始使用IOC框架的时候，会感觉系统变得不太直观。所以，引入了一个全新的框架，就会增加团队成员学习和认识的培训成本，并且在以后的运行维护中，还得让新加入者具备同样的知识体系。
 2. 由于IOC容器生成对象是通过反射方式，在运行效率上有一定的损耗。如果你要追求运行效率的话，就必须对此进行权衡。
 3. 具体到IOC框架产品(比如：Spring)来讲，需要进行大量的配制工作，比较繁琐，对于一些小的项目而言，客观上也可能加大一些工作成本。
 4. IOC框架产品本身的成熟度需要进行评估，如果引入一个不成熟的IOC框架产品，那么会影响到整个项目，所以这也是一个隐性的风险。

我们大体可以得出这样的结论：一些工作量不大的项目或者产品，不太适合使用IOC框架产品。另外，如果团队成员的知识能力欠缺，对于IOC框架产品缺乏深入的理解，也不要贸然引入。最后，特别强调运行效率的项目或者产品，也不太适合引入IOC框架产品，像WEB2.0网站就是这种情况。

> Spring框架文档：
> [https://rawchen.com/spring5][2]

[1]: https://cdn.jsdelivr.net/gh/rawchen/JsDelivr/static/default-post-image.jpg
  [2]: https://rawchen.com/spring5

广树 2021年01月18日