依赖倒置原则要求高层模块和低层模块都依赖抽象，抽象不依赖细节；Java中通过接口或抽象类定义抽象，由外部注入具体实现来解耦，如UserService依赖UserRepository接口而非其实现类。

依赖倒置（Dependency Inversion Principle，DIP）是面向对象设计中SOLID五大原则之一，核心思想是高层模块不应依赖低层模块，二者都应依赖抽象；抽象不应依赖细节，细节应依赖抽象。在Java中，它不是语法特性，而是一种设计指导思想，通过接口、抽象类等抽象机制来解耦模块间的依赖关系。

为什么需要依赖倒置？

不遵守依赖倒置时，常见写法是高层类直接new低层类实例：

❌ 反例（紧耦合）：

class UserService {
    private MySQLUserRepository repository = new MySQLUserRepository(); // 直接依赖具体实现
}

这样会导致：数据库换为Redis或MongoDB时，必须修改UserService；单元测试难以Mock；可维护性和可扩展性差。

如何用Java实现依赖倒置？

关键在于将“依赖具体实现”改为“依赖抽象”，再通过外部注入具体实现：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

立即学习“Java免费学习笔记（深入）”；

• 定义接口（抽象）描述行为，如UserRepository
• 让低层模块实现该接口（如MySQLUserRepository、RedisUserRepository）
• 高层模块（如UserService）只持有接口类型字段，并通过构造器/Setter注入具体实现
• 依赖关系由外部（如Spring容器、工厂类或测试代码）控制，而非在类内部硬编码

✅ 正例（符合DIP）：

interface UserRepository {
    User findById(Long id);
}
<p>class MySQLUserRepository implements UserRepository { /<em> ... </em>/ }
class RedisUserRepository implements UserRepository { /<em> ... </em>/ }</p><p>class UserService {
private final UserRepository repository; // 依赖抽象，不关心谁实现</p><pre class="brush:php;toolbar:false;">public UserService(UserRepository repository) { // 构造注入
    this.repository = repository;
}

}

依赖倒置 ≠ 依赖注入，但常配合使用

依赖倒置是设计原则，强调“谁依赖谁”的方向；依赖注入（DI）是实现手段，解决“怎么把依赖给进来”的问题。Spring框架的@Autowired、构造器注入等，都是落实依赖倒置的常用方式。但即使不用Spring，手动传入实现类（比如测试时传入Mock对象），也已体现DIP思想。

常见误区提醒

• 误以为“用了接口就自动满足DIP”——若高层仍自己new实现类，只是形式上用了接口，本质仍是依赖细节
• 过度抽象：不是每个类都要抽接口，只对可能变化或需替换的部分（如数据源、支付渠道、通知方式）抽象
• 混淆依赖倒置与控制反转（IoC）：IoC是更广的概念，DI是IoC的一种，DIP是指导IoC/DI如何设计的准则