关于IOC相对于工厂模式的优势
来源：2-8 深度理论课总结
数字A
2021-09-22 19:25:38
在听完老师讲的理论部分后，对IOC控制反转有了一个大概的认识：用IOC容器来控制类的注入，而不是用类来引入类。
但是，对于为什么要用IOC还是非常模糊。老师在最先的课程里举了个例子：IOC容器类似中心的齿轮，将原先互相纠缠的四个齿轮分开，用中心的齿轮去控制它们。
因此，最初我是以为，IOC是为了降低类与类之间关联性，最直接的体现即控制类（Controller）不会发生变化。但是之前提到过的工厂模式，一样通过英雄的工厂和反射的方式，实现了不改动控制类，只用修改配置中的英雄名，或者由用户输入不同英雄名。
工厂模式虽然还是类引用类，但已经降低了类与类之间的关联性。
我将二者进行比较，将类加入IOC容器，只有类的构造函数带有参数的实例化会方便一些，想问一下老师，IOC容器相对于工厂模式的优势，就在于：含参的实例化呢？
P.S:因为只会一些java基础，之前的IOC作业花了两三天也看不太明白，只懂些基础概念，所以先看了老师的理论课，还望老师见谅：）
1回答
-
无心铁憨憨
2022-12-14
IOC其本质上，它就是一个超级超级大的工厂，里面也是用的工厂模式+反射机制来完成对象的实例化。
只不过在使用模式上与我们自己写的工厂类是相反的。
一个是我们主动向工厂要，例如：xxxFactory.getBean()。
一个是自动的给我们注入我们需要的，例如 @Autowired
如果说你能实现一个超级大的工厂，并且拥有依赖注入的功能，那么就可以说，你自己实现了一个IOC容器。
依赖注入 + 对象实例化 其实就是控制反转这个思想的一个具体实现。
控制反转体现在两点：
对象实例化的控制权由我们，反转给了由容器控制
对象注入时机的控制权由我们，反转给了由容器控制
关于第二点，我个人觉得不是很好理解，打个不是很恰当的比方：
当注入的控制权在于我们手上的时候：
假设业务进行到某个节点了，我们需要调用另外一个对象的方法，这时由我们自己new一个对象出来，或者向容器要这样一个对象，然后使用它，也可以在这个节点之前，我们提前获取到这个对象，什么时候获取，完全由我们决定。当注入的控制权在容器手上的时候：
容器可能在创建某个对象的时候，就将该对象所需要依赖的所有类给进行注入了进来，也可能在具体需要用到这个类的时候再进行注入，这个注入我们是无感知的。
再比如说课程中有讲到@Lazy这个注解，明明我们已经在类上打上了这个注解，怎么它还是提前被创建了出来并进行了注入？
所以说，控制权在容器，什么时候创建，什么时候注入由容器来决定。
以上都是个人理解，欢迎讨论！
1
相似问题