• 我们在组件中用”components“声明依赖的组件时，也是一种依赖注入。也许有人说，注入的明明是具体的组件”实现”而不是”抽象”啊？ 组件B依赖组件A，但在组件B中根本没有去 new 组件A，也没有管A什么时候创建，什么时候销毁，需要怎么初始化，只是为了告诉Vue这个IoC容器：组件B依赖组件A这个事情，组件的A的init compile mount destroy 这些具体的流程和实现的管理不需要B去关心，因此这个声明可以看做是依赖了A的”抽象”。这里的”抽象”并不一定是类似Java的``”Interface”这种形式。

• 控制反转(IoC)容器，就是统一管理各个实现如何初始化、从生到死整个过程的超级管家，Vue框架本身就干了这个事情，当你用Vue.component，Vue.use把组件注册到Vue里面的时候，这个组件的实例什么时候挂载到什么地方，都可以看作由Vue这个IoC容器来控制的。

• 上面说Vue的父子组件之间直接声明components是一种依赖注入，还有一个更明显的inject provide直接给所有后代组件都注入依赖。同样，inject/provide注入给子孙后代组件，这些后代也不用管祖先组件是怎么创建和销毁的。

Angular从1.x的AngularJS，在参数中直接传递依赖组件的字符串，到后来新的Angular框架，都具有非常明显的IoC和DI的特征。而require.js这类工具解决的不是对象与对象之间的耦合问题，所以不完全算依赖注入和控制反转。

另一个非前端的例子，Node.js服务端框架 nest.js，和Java Spring以及Angular的用法非常类似，可以阅读官方文档，也有对IoC和DI的解释和具体使用示例，讲的非常详尽。

具体看本文章。

因此，如果项目相对复杂，开始用这些前后端框架，构造器代码中很少 new 非DTO/VO/PO对象出来的时候，就已经在欢快地使用依赖注入了，而IoC容器就是那个为你管理这些具体实现对象的生与死的幕后Boss。

依赖注入的问题和局限性

依赖注入一定是”好的模式”吗？

不完全是。今天我去餐馆说要一份不辣的牛肉面，结果上来一份巨辣无比的牛肉面。这就是”信息隐藏”的代价。在Java中，SpringBoot已经把IoC和DI发展的淋漓尽致了，一个@EnableAutoConfiguration注解，背后做了很多黑箱的事情，各种约定式的配置直接告诉Spring容器该做什么事情，甚至无需写一行代码。物极必反，这样反而让项目容易出现过多冗余的依赖、大量被Spring容器中的Bean在背后难以控制、一个接口存在过多的实现类、不确定的互相影响、依赖加载顺序问题等等。

虽然可能存在这些问题，但我觉得在以面向对象编程为主的复杂系统引入IoC容器和DI仍然是有必要的，上述这些问题也有办法避免或解决。让对象自己管理所依赖对象的生命周期，就像直接雇一个厨师来做牛肉面一样简单粗暴，但更容易违背迪米特法则等其他OOP的理念，项目的可扩展性和可维护性会受到更强的制约。这里前提是OOP情况下的建议，当然OOP也有一些局限性，不一定非要用OOP作为编程范式。

另一个场景，如果只是一些简单的页面或服务，没有复杂的组件/服务之间的交互，是没有必要为了用DI而用DI的。

结尾

依赖注入(DI)和控制反转(IoC)是具体的手段，是OOP理论中依赖倒置原则的体现形式，通过信息隐藏来降低对象之间的耦合，这就是依赖倒置解决的问题。这种思想的运用不限于语言和框架。像Java Spring用工厂/模板方法/代理/单例模式、、注解、反射、动态代理这一系列设计模式和相关技术实现了IoC容器，而在没有类似Spring的语言和框架中运用这一思想的时候，无需实现如此复杂的框架，只要达到依赖倒置的”实现”和”实现”的解耦效果即可。

💫点击直接资料领取💫

​ 这里有各种学习资料还有有有趣好玩的编程项目，更有难寻的各种资源。 ​ ​