控制反转(IoC)是高层设计思想,指将对象控制权从代码移交容器;依赖注入(DI)是其实现手段,指通过构造、Setter等方式由容器注入依赖。IoC回答“谁控制”,DI回答“如何传”,二者维度不同,不可互换。

如果您在学习Spring或面向对象设计时遇到“控制反转”和“依赖注入”两个术语,却难以区分其本质差异,则可能是由于二者常被混用,但实际处于不同抽象层级。以下是厘清这一区别的具体说明:
一、控制反转(IoC)是一种设计思想
控制反转描述的是程序执行控制权的转移过程,它不特指某段代码或某种技术,而是一种高层级的设计原则。其核心在于将对象的生命周期管理、依赖关系建立等控制行为,从应用程序内部移交给外部容器或框架来承担。
1、在传统编程中,类A需要使用类B时,通常在A内部直接通过new B()创建B的实例;
2、此时A完全掌控B的创建时机、方式与生命周期,属于“正转”;
3、当引入IoC后,A不再负责创建B,而是由外部容器(如Spring ApplicationContext)统一管理B的实例化与供给;
4、A仅声明对B的依赖,具体何时创建、如何复用、是否单例等均由容器决定;
5、这种控制权从A向容器的移交,即为“反转”——控制权由程序员代码转向框架容器。
二、依赖注入(DI)是实现IoC的具体手段
依赖注入并非独立存在的概念,而是IoC思想落地时最常用、最典型的实现机制。它聚焦于“如何把依赖对象送入目标对象”,强调的是依赖传递的方式与路径,而非控制权归属本身。
1、构造函数注入:目标类通过构造参数接收依赖,如public UserService(UserRepository repo);
2、Setter方法注入:依赖通过公共setter方法设置,如setUserRepository(UserRepository repo);
3、接口注入:目标类实现特定接口,由外部调用接口方法注入依赖(实践中极少使用);
4、无论采用哪种形式,DI本身并不改变控制权归属,但它使IoC得以在代码中可操作、可配置、可测试;
5、没有DI,IoC可能通过依赖查找(Service Locator)等方式实现,但DI已成为事实标准。
三、二者不可互换的根本原因
IoC与DI分属不同维度:IoC回答“谁来控制”,DI回答“怎么传递”。混淆二者往往源于Spring文档与日常开发中将DI作为IoC的默认表达,导致概念边界模糊。
1、一个系统可以存在IoC但不使用DI,例如通过JNDI查找服务,控制权已交予容器,但未发生“注入”动作;
2、DI必须依附于某种控制权上收机制,否则只是普通参数传值,无法构成IoC;
3、Martin Fowler明确指出:“Dependency Injection is a specific form of Inversion of Control”;
4、若仅在类内部调用另一个类的setter方法并传入实例,该行为本身不是DI,因控制权仍在当前类;
5、只有当注入行为由外部容器驱动、且脱离目标类主动调用逻辑时,才构成真正的DI。
四、代码层面的对照验证
对比以下两段代码可直观识别差异:
1、非IoC非DI写法:private UserRepository repo = new UserRepositoryImpl();;
2、IoC + DI写法(构造注入):private final UserRepository repo; public UserService(UserRepository repo) { this.repo = repo; };
3、IoC + 非DI写法(依赖查找):private UserRepository repo = (UserRepository) context.getBean("userRepository");;
4、DI但非IoC写法(手动注入):UserService service = new UserService(); service.setRepo(new UserRepositoryImpl());;
5、仅第2种同时满足IoC(控制权交予容器)与DI(依赖由外部注入)双重条件。
五、解耦效果的体现层级
IoC与DI共同服务于解耦目标,但作用位置不同:IoC在架构层面切断对象创建链路,DI在实现层面切断对象获取链路。二者协同才能达成真正松耦合。
1、仅做IoC(如统一工厂管理)但不注入,调用方仍需显式向工厂索要实例,耦合点从new转移到getBean;
2、仅做DI(如手工构造并传参)但无容器接管,依赖变更仍需修改调用方代码,未实现运行时替换;
3、IoC容器配合DI后,UserService实现类可随时更换为MockUserRepository,无需修改UserController任何一行代码;
4、替换依据不再是硬编码类型,而是接口契约与配置元数据;
5、解耦的最终落点是接口而非实现,而IoC+DI为此提供了基础设施保障。










