一、从一个耦合的案例说起在正式讲解 IOC 之前我们先看一段几乎每个 Java 程序员都写过的代码。假设我们正在开发一个用户管理模块需要实现「用户注册」「用户查询」等功能。按照最直观的思路我们会这样组织代码// 数据访问层负责操作数据库 public class UserDao { public User findUserById(Long id) { // 查询数据库这里省略具体实现 System.out.println(查询用户 id); return new User(id, 张三); } public void saveUser(User user) { // 保存用户到数据库 System.out.println(保存用户 user.getName()); } } // 业务逻辑层负责业务规则 public class UserService { // 直接在内部创建依赖对象 private UserDao userDao new UserDao(); public User getUser(Long id) { // 业务校验、日志等逻辑省略 return userDao.findUserById(id); } public void registerUser(User user) { // 业务校验逻辑省略 userDao.saveUser(user); } } // 表现层对外提供接口 public class UserController { private UserService userService new UserService(); public User queryUser(Long id) { return userService.getUser(id); } } // 测试入口 public class Main { public static void main(String[] args) { UserController controller new UserController(); User user controller.queryUser(1L); System.out.println(user); } }这段代码在功能上没有任何问题运行起来也能正常输出结果。如果项目只有这一个模块、只有你一个人维护、并且永远不会修改那么它甚至可以说是「简单直接、清晰易懂」。但现实世界中的软件项目从来不是这样。我们先来推演几个非常常见的真实场景场景一更换数据源。假设公司上层决定从 MySQL 迁移到国产数据库达梦或者数据访问层要统一改为 MyBatis。此时UserDao内部需要做大量修改。由于UserService直接new了UserDao一旦UserDao的构造方式、初始化参数发生变化UserService的代码也必须跟着改。更麻烦的是如果有十几个业务类都直接new了UserDao那么这十几个类都要逐一修改。场景二单元测试。我们想单独测试UserService的业务逻辑而不希望依赖真实的数据库。理想情况下我们希望给UserService注入一个「假的」UserDao比如内存实现或者 Mock 对象。但在上面的代码中UserDao被硬编码在UserService内部测试时根本无法替换只能真的去连数据库。场景三多环境配置。开发、测试、生产环境的数据库地址完全不同。传统做法是通过配置文件让UserDao读取不同配置但当依赖关系层层嵌套、数量庞大时整个系统的初始化顺序和配置管理会变得异常复杂。场景四多人协作。团队中 A 负责UserDaoB 负责UserService。A 的UserDao还没有开发完成B 的UserService却已经写完并想联调。在硬编码的情况下B 必须等 A 完成后才能继续开发效率严重受阻。这些问题的本质可以用两个字概括耦合。二、什么是耦合2.1 耦合的定义耦合Coupling是软件工程中衡量模块之间关联程度的一个指标。它描述的是「一个模块的变化会在多大程度上影响另一个模块」。耦合度越高模块之间的独立性就越差一个模块的改动越容易引发连锁反应耦合度越低模块之间的独立性就越好代码越容易维护、扩展和测试。在上面的例子中UserService和UserDao之间就存在较高的耦合。具体体现在以下几点创建耦合UserService直接通过new UserDao()创建了UserDao实例它必须知道UserDao的具体类名和构造方法。类型耦合UserService的成员变量类型写死为UserDao而不是它的抽象接口使得替换实现变得困难。生命周期耦合UserDao何时创建、何时销毁完全由UserService控制两者生命周期绑定在一起。2.2 耦合的分类在软件工程理论中耦合按从高到低可以大致分为以下几个等级耦合类型特点维护成本内容耦合一个模块直接访问另一个模块的内部数据或代码极高公共耦合多个模块通过公共全局数据交互高控制耦合一个模块通过参数控制另一个模块的行为逻辑较高标记耦合模块间通过复杂的数据结构传递信息中数据耦合模块间只通过简单参数传递数据低零耦合模块之间完全独立没有直接联系最低我们日常业务开发中的「直接new对象」严格来说属于一种较为紧密的耦合。虽然它还没恶劣到「内容耦合」的程度但它让上层模块牢牢依赖下层模块的具体实现带来了前面提到的测试难、替换难、并行开发难等问题。2.3 高耦合的危害高耦合代码在项目初期往往感受不到痛因为一切都能跑通。但随着项目演进它的危害会逐步显现牵一发而动全身修改底层实现所有直接依赖它的上层代码都要跟着改。测试成本高无法对单个类进行隔离测试单元测试被迫变成集成测试。复用性差一个与具体实现强绑定的类很难被其他模块或项目复用。并行开发受阻上下游必须严格串行开发依赖方必须等被依赖方完成。可读性下降依赖关系隐藏在代码内部光看类定义很难理清系统全貌。因此解耦是软件设计中的一项核心目标。而 IOC 正是实现解耦的经典手段之一。三、控制反转 IOC 到底是什么3.1 IOC 的定义IOC 全称 Inversion of Control中文翻译为「控制反转」。它是面向对象编程中的一种设计原则核心思想是把对象创建和对象之间依赖关系的管理权从程序代码中转移到外部容器中。在传统方式下对象的创建由程序主动完成public class UserService { // 程序主动创建控制权在 UserService 自己手里 private UserDao userDao new UserDao(); }引入 IOC 之后UserService不再自己创建UserDao而是由外部容器创建好并「注入」给它public class UserService { // 依赖由外部容器注入控制权从 UserService 转移到了容器 private final UserDao userDao; public UserService(UserDao userDao) { this.userDao userDao; } }代码层面的变化看起来很小但从「我主动new一个对象」变成「别人把对象给我」这是思维上的一次根本性转变。3.2 到底反转了什么很多初学者对「反转」两个字感到困惑到底是谁反转了谁在没有 IOC 的传统程序里控制流由程序自己掌控。UserService决定在什么时候、以什么方式创建UserDao。程序员在编写代码时就明确规定了依赖的获取方式。在 IOC 模式下控制权被「反转」给了容器。程序不再关心对象从哪里来、如何创建它只声明「我需要一个UserDao」然后等待容器把对象交给它。创建对象、管理生命周期、装配依赖关系这些工作全部由容器统一负责。所以「反转」指的是获取依赖对象的控制权从程序自身反转给了外部容器。3.3 好莱坞原则IOC 有一个非常形象的类比叫做「好莱坞原则」Dont call us, well call you不要打电话给我们我们会打给你。在传统模式中一个组件需要依赖时会主动「打电话」给容器或者直接自己创建即我需要UserDao所以我自己new一个。如果需要参数我自己去配置文件里读。在 IOC 模式中组件「留了电话」但不会主动打而是等待容器「打过来」我声明自己需要一个UserDao。容器在合适的时机调用我的构造方法或 setter 方法把UserDao送进来。理解了好莱坞原则就理解了 IOC 的哲学内核组件专注于自己的职责依赖的获取和管理交给框架。3.4 IOC 不是新发明IOC 作为一种思想其实远早于 Spring 的诞生。早在图形界面编程、框架设计的实践中就已经存在控制反转的影子。比较典型的例子是事件监听机制。当我们在 Swing、Android 或其他 GUI 框架中注册按钮点击事件时我们不会自己写一个死循环去不断检查「按钮有没有被点击」而是注册一个回调监听器然后由框架在事件发生时调用我们button.addActionListener(new ActionListener() { Override public void actionPerformed(ActionEvent e) { // 按钮被点击时由框架回调这个方法 System.out.println(按钮被点击了); } });这里「何时处理点击事件」的控制权从应用程序反转给了 GUI 框架。这与 IOC 容器管理依赖创建是同一个思想。另一个例子是模板方法模式。父类定义算法骨架子类实现具体步骤由父类在合适时机调用子类的方法也是一种控制反转。由此可见IOC 是一个通用设计思想Spring 的 IOC 容器只是它在依赖管理领域的一个成功落地。四、依赖注入 DI4.1 DI 与 IOC 的关系DI 全称 Dependency Injection中文翻译为「依赖注入」。它和 IOC 经常被一起提起以至于很多人以为它们是同一个东西其实两者描述的是同一枚硬币的两面。IOC 是思想控制反转强调的是「控制权的转移」这种设计原则。DI 是实现依赖注入强调的是「如何把依赖交给对象」这种具体实现方式。打个比方IOC 好比「我不自己做饭了改为点外卖」这是一个理念DI 好比「外卖小哥把餐送到我家门口」这是具体落地方式。要实现 IOC业界主流手段就是 DI。当然理论上也存在其他实现方式例如 Service Locator服务定位器但 DI 因其清晰、可测试等优点成为主流。4.2 构造方法注入构造方法注入是 Spring 官方推荐的第一选择。它要求依赖通过构造方法传入对象一旦创建完成其依赖就是完整、不可变的。public class UserService { private final UserDao userDao; // 通过构造方法注入依赖 public UserService(UserDao userDao) { this.userDao userDao; } }构造注入的优点非常明显依赖不可变依赖字段可以声明为final对象创建后无法被篡改线程安全。依赖完整性创建对象时必须传入所有必要依赖不允许出现「半初始化」状态。有利于测试测试时代码意图清晰构造方法签名直接告诉我们这个类需要哪些依赖。避免隐藏依赖不会出现依赖被偷偷注入的情况所有依赖都显式列出。构造注入的缺点主要是当依赖较多时构造方法参数列表会变长不过依赖过多本身往往是类职责过多的信号应当考虑拆分。4.3 Setter 方法注入Setter 注入通过 setter 方法设置依赖适用于可选依赖或者需要动态变更依赖的场景。public class UserService { private UserDao userDao; // 通过 setter 注入依赖 public void setUserDao(UserDao userDao) { this.userDao userDao; } }Setter 注入的优点是灵活依赖可以在对象创建之后被替换缺点是依赖不是强制的容易产生「对象已经创建但依赖还没注入」的不完整状态而且依赖字段无法声明为final。在实际项目中我的建议是必需依赖使用构造注入可选依赖使用 Setter 注入。4.4 字段注入字段注入就是我们最熟悉的Autowired直接标注在字段上的方式Service public class UserService { Autowired private UserDao userDao; }这种方式写起来最简洁Spring Boot 项目里随处可见。但它其实存在不少隐患隐藏依赖看类定义无法直接知道它依赖了什么必须深入字段才能发现。破坏封装依赖字段可以被外部直接访问和修改。测试麻烦单元测试时无法通过构造方法直接传入依赖必须借助反射或 Spring 上下文。易产生循环依赖掩盖问题字段注入让循环依赖更容易被「容忍」反而掩盖了设计上的不合理。Spring 官方文档明确声明字段注入是不推荐的建议优先构造注入。然而在大量存量项目和快速开发场景下字段注入依然流行。大家在实际工作中应当理解它的利弊新代码尽量向构造注入靠拢。4.5 接口注入接口注入是一种较为少见的方式它要求被注入的类实现一个特定接口该接口定义注入方法。例如// 定义注入接口 public interface UserDaoAware { void setUserDao(UserDao userDao); } public class UserService implements UserDaoAware { private UserDao userDao; Override public void setUserDao(UserDao userDao) { this.userDao userDao; } }这种方式把依赖注入的契约定义在接口层但在 Spring 生态中很少使用因为与框架耦合较重灵活性不如前几种。了解即可。五、IOC 是如何实现解耦的5.1 核心手段之一依赖倒置IOC 实现解耦本质上离不开一个经典设计原则依赖倒置原则Dependency Inversion PrincipleDIP。它是 SOLID 原则中的「D」表述为高层模块不应该依赖低层模块二者都应该依赖抽象。抽象不应该依赖细节细节应该依赖抽象。结合我们的例子方案依赖关系耦合程度传统写法UserService 直接依赖 UserDao 具体类高依赖倒置写法UserService 依赖 UserDao 接口具体实现依赖接口低要实现依赖倒置我们先从接口抽象开始。把UserDao抽象成接口让UserService只认识接口不认识任何具体实现// 抽象层定义数据访问契约 public interface UserDao { User findById(Long id); void save(User user); } // 具体实现用 JDBC、MyBatis 等方式实现接口 public class UserDaoImpl implements UserDao { Override public User findById(Long id) { System.out.println(查询用户 id); return new User(id, 张三); } Override public void save(User user) { System.out.println(保存用户 user.getName()); } } // 业务层只依赖抽象不再依赖具体实现 public class UserService { private final UserDao userDao; public UserService(UserDao userDao) { this.userDao userDao; } public User getUser(Long id) { return userDao.findById(id); } public void register(User user) { userDao.save(user); } }这样一来UserService的代码里不再出现new UserDaoImpl()它只依赖UserDao接口。将来无论把实现换成 MyBatis、JPA 还是国产数据库方案只要实现同一个接口UserService都不需要修改。这就是依赖倒置带来的解耦效果。5.2 核心手段之二容器统一管理装配依赖倒置解决了“代码里不依赖具体类”的问题但还有一个现实问题接口只是契约程序运行时总得有一个具体实现被创建出来并且被塞进UserService。如果这部分工作仍然由程序员手动完成解耦的效果会大打折扣。IOC 的第二个关键手段就是把“创建对象”和“装配依赖”这件事交给容器。以 Spring 为例我们不再手写new而是用注解声明组件及其依赖关系Repository public class UserDaoImpl implements UserDao { // 具体实现省略 } Service public class UserService { private final UserDao userDao; // Spring 容器会找到唯一的 UserDao 实现并注入进来 public UserService(UserDao userDao) { this.userDao userDao; } }Spring 容器启动时会扫描这些注解创建对应的 Bean并根据类型匹配关系完成注入。对于程序员来说组装逻辑从“手写new”变成了“声明依赖”对象的创建时机、生命周期和作用域都由容器统一管理。5.3 传统写法与 IOC 写法对比我们把前面的UserController也一并改造就能更直观地看到两者的差异// 传统写法每一层都自己 new层层硬编码 public class UserController { private UserService userService new UserService(); } // IOC 写法每一层只声明依赖由外部传入 RestController public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService userService; } }对比之后可以发现IOC 并没有让代码变少甚至很多时候注解和接口让代码看起来更多了。它的价值不在“少写几行”而在于模块边界清晰每个类只依赖抽象不关心实现细节。替换成本低更换数据源、更换实现只需要改配置或新增一个实现类。测试变得容易测试时可以直接传入 Mock 对象无需启动容器或连接数据库。对象生命周期统一管理单例、多例、作用域、销毁回调等都由容器负责。六、总结本文从一个“直接new对象”的常见案例出发梳理了耦合、控制反转和依赖注入之间的关系。核心结论可以归纳为三句话耦合是问题直接依赖具体实现会让系统变得脆弱难以测试和扩展。IOC 是思想把对象创建和依赖管理的控制权从程序自身反转到外部容器。DI 是手段通过构造注入、Setter 注入等方式把依赖交给对象。初学者理解 IOC 时最容易卡住的不是语法而是思维方式的转变。不妨反复体会好莱坞原则Dont call us, well call you。当你能从“我主动创建对象”切换到“我声明需要什么由容器给我”时IOC 的大门才算真正打开。七、常见误区与高频面试题很多同学学完概念后动手写代码时仍然容易掉进下面几个坑面试中也经常被追问。7.1 常见误区把“用了 Spring”等同于“理解了 IOC”注解只是入口理解控制权从哪里转移到哪里才是关键。只记概念不关注抽象设计如果类仍然直接依赖具体实现即使有容器解耦效果也很有限。滥用字段注入图省事大量使用Autowired字段注入会逐渐积累隐藏依赖和测试成本。遇到循环依赖先想着开启允许循环依赖的开关循环依赖往往说明职责划分有问题应先考虑重构而不是用开关掩盖。7.2 高频面试题下面几道题可以帮助你快速自检什么是 IOC它反转的到底是什么IOC 和 DI 是什么关系依赖注入有哪几种方式各自的优缺点是什么为什么 Spring 官方推荐构造方法注入依赖倒置原则和 IOC 有什么区别这些问题基本都围绕本文主线展开建议用自己的话复述一遍而不是死记答案。八、参考资料与扩展阅读如果想继续深入学习可以从以下资料入手Martin Fowler《Inversion of Control Containers and the Dependency Injection pattern》Spring Framework 官方文档IoC Container 章节Robert C. Martin《架构整洁之道》中关于依赖倒置与分层的讨论Craig Walls《Spring 实战》
面试官：IOC是如何实现解耦合的？
一、从一个耦合的案例说起在正式讲解 IOC 之前我们先看一段几乎每个 Java 程序员都写过的代码。假设我们正在开发一个用户管理模块需要实现「用户注册」「用户查询」等功能。按照最直观的思路我们会这样组织代码// 数据访问层负责操作数据库 public class UserDao { public User findUserById(Long id) { // 查询数据库这里省略具体实现 System.out.println(查询用户 id); return new User(id, 张三); } public void saveUser(User user) { // 保存用户到数据库 System.out.println(保存用户 user.getName()); } } // 业务逻辑层负责业务规则 public class UserService { // 直接在内部创建依赖对象 private UserDao userDao new UserDao(); public User getUser(Long id) { // 业务校验、日志等逻辑省略 return userDao.findUserById(id); } public void registerUser(User user) { // 业务校验逻辑省略 userDao.saveUser(user); } } // 表现层对外提供接口 public class UserController { private UserService userService new UserService(); public User queryUser(Long id) { return userService.getUser(id); } } // 测试入口 public class Main { public static void main(String[] args) { UserController controller new UserController(); User user controller.queryUser(1L); System.out.println(user); } }这段代码在功能上没有任何问题运行起来也能正常输出结果。如果项目只有这一个模块、只有你一个人维护、并且永远不会修改那么它甚至可以说是「简单直接、清晰易懂」。但现实世界中的软件项目从来不是这样。我们先来推演几个非常常见的真实场景场景一更换数据源。假设公司上层决定从 MySQL 迁移到国产数据库达梦或者数据访问层要统一改为 MyBatis。此时UserDao内部需要做大量修改。由于UserService直接new了UserDao一旦UserDao的构造方式、初始化参数发生变化UserService的代码也必须跟着改。更麻烦的是如果有十几个业务类都直接new了UserDao那么这十几个类都要逐一修改。场景二单元测试。我们想单独测试UserService的业务逻辑而不希望依赖真实的数据库。理想情况下我们希望给UserService注入一个「假的」UserDao比如内存实现或者 Mock 对象。但在上面的代码中UserDao被硬编码在UserService内部测试时根本无法替换只能真的去连数据库。场景三多环境配置。开发、测试、生产环境的数据库地址完全不同。传统做法是通过配置文件让UserDao读取不同配置但当依赖关系层层嵌套、数量庞大时整个系统的初始化顺序和配置管理会变得异常复杂。场景四多人协作。团队中 A 负责UserDaoB 负责UserService。A 的UserDao还没有开发完成B 的UserService却已经写完并想联调。在硬编码的情况下B 必须等 A 完成后才能继续开发效率严重受阻。这些问题的本质可以用两个字概括耦合。二、什么是耦合2.1 耦合的定义耦合Coupling是软件工程中衡量模块之间关联程度的一个指标。它描述的是「一个模块的变化会在多大程度上影响另一个模块」。耦合度越高模块之间的独立性就越差一个模块的改动越容易引发连锁反应耦合度越低模块之间的独立性就越好代码越容易维护、扩展和测试。在上面的例子中UserService和UserDao之间就存在较高的耦合。具体体现在以下几点创建耦合UserService直接通过new UserDao()创建了UserDao实例它必须知道UserDao的具体类名和构造方法。类型耦合UserService的成员变量类型写死为UserDao而不是它的抽象接口使得替换实现变得困难。生命周期耦合UserDao何时创建、何时销毁完全由UserService控制两者生命周期绑定在一起。2.2 耦合的分类在软件工程理论中耦合按从高到低可以大致分为以下几个等级耦合类型特点维护成本内容耦合一个模块直接访问另一个模块的内部数据或代码极高公共耦合多个模块通过公共全局数据交互高控制耦合一个模块通过参数控制另一个模块的行为逻辑较高标记耦合模块间通过复杂的数据结构传递信息中数据耦合模块间只通过简单参数传递数据低零耦合模块之间完全独立没有直接联系最低我们日常业务开发中的「直接new对象」严格来说属于一种较为紧密的耦合。虽然它还没恶劣到「内容耦合」的程度但它让上层模块牢牢依赖下层模块的具体实现带来了前面提到的测试难、替换难、并行开发难等问题。2.3 高耦合的危害高耦合代码在项目初期往往感受不到痛因为一切都能跑通。但随着项目演进它的危害会逐步显现牵一发而动全身修改底层实现所有直接依赖它的上层代码都要跟着改。测试成本高无法对单个类进行隔离测试单元测试被迫变成集成测试。复用性差一个与具体实现强绑定的类很难被其他模块或项目复用。并行开发受阻上下游必须严格串行开发依赖方必须等被依赖方完成。可读性下降依赖关系隐藏在代码内部光看类定义很难理清系统全貌。因此解耦是软件设计中的一项核心目标。而 IOC 正是实现解耦的经典手段之一。三、控制反转 IOC 到底是什么3.1 IOC 的定义IOC 全称 Inversion of Control中文翻译为「控制反转」。它是面向对象编程中的一种设计原则核心思想是把对象创建和对象之间依赖关系的管理权从程序代码中转移到外部容器中。在传统方式下对象的创建由程序主动完成public class UserService { // 程序主动创建控制权在 UserService 自己手里 private UserDao userDao new UserDao(); }引入 IOC 之后UserService不再自己创建UserDao而是由外部容器创建好并「注入」给它public class UserService { // 依赖由外部容器注入控制权从 UserService 转移到了容器 private final UserDao userDao; public UserService(UserDao userDao) { this.userDao userDao; } }代码层面的变化看起来很小但从「我主动new一个对象」变成「别人把对象给我」这是思维上的一次根本性转变。3.2 到底反转了什么很多初学者对「反转」两个字感到困惑到底是谁反转了谁在没有 IOC 的传统程序里控制流由程序自己掌控。UserService决定在什么时候、以什么方式创建UserDao。程序员在编写代码时就明确规定了依赖的获取方式。在 IOC 模式下控制权被「反转」给了容器。程序不再关心对象从哪里来、如何创建它只声明「我需要一个UserDao」然后等待容器把对象交给它。创建对象、管理生命周期、装配依赖关系这些工作全部由容器统一负责。所以「反转」指的是获取依赖对象的控制权从程序自身反转给了外部容器。3.3 好莱坞原则IOC 有一个非常形象的类比叫做「好莱坞原则」Dont call us, well call you不要打电话给我们我们会打给你。在传统模式中一个组件需要依赖时会主动「打电话」给容器或者直接自己创建即我需要UserDao所以我自己new一个。如果需要参数我自己去配置文件里读。在 IOC 模式中组件「留了电话」但不会主动打而是等待容器「打过来」我声明自己需要一个UserDao。容器在合适的时机调用我的构造方法或 setter 方法把UserDao送进来。理解了好莱坞原则就理解了 IOC 的哲学内核组件专注于自己的职责依赖的获取和管理交给框架。3.4 IOC 不是新发明IOC 作为一种思想其实远早于 Spring 的诞生。早在图形界面编程、框架设计的实践中就已经存在控制反转的影子。比较典型的例子是事件监听机制。当我们在 Swing、Android 或其他 GUI 框架中注册按钮点击事件时我们不会自己写一个死循环去不断检查「按钮有没有被点击」而是注册一个回调监听器然后由框架在事件发生时调用我们button.addActionListener(new ActionListener() { Override public void actionPerformed(ActionEvent e) { // 按钮被点击时由框架回调这个方法 System.out.println(按钮被点击了); } });这里「何时处理点击事件」的控制权从应用程序反转给了 GUI 框架。这与 IOC 容器管理依赖创建是同一个思想。另一个例子是模板方法模式。父类定义算法骨架子类实现具体步骤由父类在合适时机调用子类的方法也是一种控制反转。由此可见IOC 是一个通用设计思想Spring 的 IOC 容器只是它在依赖管理领域的一个成功落地。四、依赖注入 DI4.1 DI 与 IOC 的关系DI 全称 Dependency Injection中文翻译为「依赖注入」。它和 IOC 经常被一起提起以至于很多人以为它们是同一个东西其实两者描述的是同一枚硬币的两面。IOC 是思想控制反转强调的是「控制权的转移」这种设计原则。DI 是实现依赖注入强调的是「如何把依赖交给对象」这种具体实现方式。打个比方IOC 好比「我不自己做饭了改为点外卖」这是一个理念DI 好比「外卖小哥把餐送到我家门口」这是具体落地方式。要实现 IOC业界主流手段就是 DI。当然理论上也存在其他实现方式例如 Service Locator服务定位器但 DI 因其清晰、可测试等优点成为主流。4.2 构造方法注入构造方法注入是 Spring 官方推荐的第一选择。它要求依赖通过构造方法传入对象一旦创建完成其依赖就是完整、不可变的。public class UserService { private final UserDao userDao; // 通过构造方法注入依赖 public UserService(UserDao userDao) { this.userDao userDao; } }构造注入的优点非常明显依赖不可变依赖字段可以声明为final对象创建后无法被篡改线程安全。依赖完整性创建对象时必须传入所有必要依赖不允许出现「半初始化」状态。有利于测试测试时代码意图清晰构造方法签名直接告诉我们这个类需要哪些依赖。避免隐藏依赖不会出现依赖被偷偷注入的情况所有依赖都显式列出。构造注入的缺点主要是当依赖较多时构造方法参数列表会变长不过依赖过多本身往往是类职责过多的信号应当考虑拆分。4.3 Setter 方法注入Setter 注入通过 setter 方法设置依赖适用于可选依赖或者需要动态变更依赖的场景。public class UserService { private UserDao userDao; // 通过 setter 注入依赖 public void setUserDao(UserDao userDao) { this.userDao userDao; } }Setter 注入的优点是灵活依赖可以在对象创建之后被替换缺点是依赖不是强制的容易产生「对象已经创建但依赖还没注入」的不完整状态而且依赖字段无法声明为final。在实际项目中我的建议是必需依赖使用构造注入可选依赖使用 Setter 注入。4.4 字段注入字段注入就是我们最熟悉的Autowired直接标注在字段上的方式Service public class UserService { Autowired private UserDao userDao; }这种方式写起来最简洁Spring Boot 项目里随处可见。但它其实存在不少隐患隐藏依赖看类定义无法直接知道它依赖了什么必须深入字段才能发现。破坏封装依赖字段可以被外部直接访问和修改。测试麻烦单元测试时无法通过构造方法直接传入依赖必须借助反射或 Spring 上下文。易产生循环依赖掩盖问题字段注入让循环依赖更容易被「容忍」反而掩盖了设计上的不合理。Spring 官方文档明确声明字段注入是不推荐的建议优先构造注入。然而在大量存量项目和快速开发场景下字段注入依然流行。大家在实际工作中应当理解它的利弊新代码尽量向构造注入靠拢。4.5 接口注入接口注入是一种较为少见的方式它要求被注入的类实现一个特定接口该接口定义注入方法。例如// 定义注入接口 public interface UserDaoAware { void setUserDao(UserDao userDao); } public class UserService implements UserDaoAware { private UserDao userDao; Override public void setUserDao(UserDao userDao) { this.userDao userDao; } }这种方式把依赖注入的契约定义在接口层但在 Spring 生态中很少使用因为与框架耦合较重灵活性不如前几种。了解即可。五、IOC 是如何实现解耦的5.1 核心手段之一依赖倒置IOC 实现解耦本质上离不开一个经典设计原则依赖倒置原则Dependency Inversion PrincipleDIP。它是 SOLID 原则中的「D」表述为高层模块不应该依赖低层模块二者都应该依赖抽象。抽象不应该依赖细节细节应该依赖抽象。结合我们的例子方案依赖关系耦合程度传统写法UserService 直接依赖 UserDao 具体类高依赖倒置写法UserService 依赖 UserDao 接口具体实现依赖接口低要实现依赖倒置我们先从接口抽象开始。把UserDao抽象成接口让UserService只认识接口不认识任何具体实现// 抽象层定义数据访问契约 public interface UserDao { User findById(Long id); void save(User user); } // 具体实现用 JDBC、MyBatis 等方式实现接口 public class UserDaoImpl implements UserDao { Override public User findById(Long id) { System.out.println(查询用户 id); return new User(id, 张三); } Override public void save(User user) { System.out.println(保存用户 user.getName()); } } // 业务层只依赖抽象不再依赖具体实现 public class UserService { private final UserDao userDao; public UserService(UserDao userDao) { this.userDao userDao; } public User getUser(Long id) { return userDao.findById(id); } public void register(User user) { userDao.save(user); } }这样一来UserService的代码里不再出现new UserDaoImpl()它只依赖UserDao接口。将来无论把实现换成 MyBatis、JPA 还是国产数据库方案只要实现同一个接口UserService都不需要修改。这就是依赖倒置带来的解耦效果。5.2 核心手段之二容器统一管理装配依赖倒置解决了“代码里不依赖具体类”的问题但还有一个现实问题接口只是契约程序运行时总得有一个具体实现被创建出来并且被塞进UserService。如果这部分工作仍然由程序员手动完成解耦的效果会大打折扣。IOC 的第二个关键手段就是把“创建对象”和“装配依赖”这件事交给容器。以 Spring 为例我们不再手写new而是用注解声明组件及其依赖关系Repository public class UserDaoImpl implements UserDao { // 具体实现省略 } Service public class UserService { private final UserDao userDao; // Spring 容器会找到唯一的 UserDao 实现并注入进来 public UserService(UserDao userDao) { this.userDao userDao; } }Spring 容器启动时会扫描这些注解创建对应的 Bean并根据类型匹配关系完成注入。对于程序员来说组装逻辑从“手写new”变成了“声明依赖”对象的创建时机、生命周期和作用域都由容器统一管理。5.3 传统写法与 IOC 写法对比我们把前面的UserController也一并改造就能更直观地看到两者的差异// 传统写法每一层都自己 new层层硬编码 public class UserController { private UserService userService new UserService(); } // IOC 写法每一层只声明依赖由外部传入 RestController public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService userService; } }对比之后可以发现IOC 并没有让代码变少甚至很多时候注解和接口让代码看起来更多了。它的价值不在“少写几行”而在于模块边界清晰每个类只依赖抽象不关心实现细节。替换成本低更换数据源、更换实现只需要改配置或新增一个实现类。测试变得容易测试时可以直接传入 Mock 对象无需启动容器或连接数据库。对象生命周期统一管理单例、多例、作用域、销毁回调等都由容器负责。六、总结本文从一个“直接new对象”的常见案例出发梳理了耦合、控制反转和依赖注入之间的关系。核心结论可以归纳为三句话耦合是问题直接依赖具体实现会让系统变得脆弱难以测试和扩展。IOC 是思想把对象创建和依赖管理的控制权从程序自身反转到外部容器。DI 是手段通过构造注入、Setter 注入等方式把依赖交给对象。初学者理解 IOC 时最容易卡住的不是语法而是思维方式的转变。不妨反复体会好莱坞原则Dont call us, well call you。当你能从“我主动创建对象”切换到“我声明需要什么由容器给我”时IOC 的大门才算真正打开。七、常见误区与高频面试题很多同学学完概念后动手写代码时仍然容易掉进下面几个坑面试中也经常被追问。7.1 常见误区把“用了 Spring”等同于“理解了 IOC”注解只是入口理解控制权从哪里转移到哪里才是关键。只记概念不关注抽象设计如果类仍然直接依赖具体实现即使有容器解耦效果也很有限。滥用字段注入图省事大量使用Autowired字段注入会逐渐积累隐藏依赖和测试成本。遇到循环依赖先想着开启允许循环依赖的开关循环依赖往往说明职责划分有问题应先考虑重构而不是用开关掩盖。7.2 高频面试题下面几道题可以帮助你快速自检什么是 IOC它反转的到底是什么IOC 和 DI 是什么关系依赖注入有哪几种方式各自的优缺点是什么为什么 Spring 官方推荐构造方法注入依赖倒置原则和 IOC 有什么区别这些问题基本都围绕本文主线展开建议用自己的话复述一遍而不是死记答案。八、参考资料与扩展阅读如果想继续深入学习可以从以下资料入手Martin Fowler《Inversion of Control Containers and the Dependency Injection pattern》Spring Framework 官方文档IoC Container 章节Robert C. Martin《架构整洁之道》中关于依赖倒置与分层的讨论Craig Walls《Spring 实战》
