依赖倒置原则（DIP）要求高层模块和底层模块都依赖抽象（接口或抽象类），而非彼此直接依赖；通过定义统一契约（如Database接口）、实现类各自遵循、依赖注入动态绑定，提升系统灵活性、可测试性与可维护性。
依赖倒置原则（DIP）在 Java 面向对象设计中，核心作用是把高层模块和底层实现之间的“硬绑定”拆开，换成双方都面向同一个抽象（接口或抽象类）协作。它不是让代码不依赖，而是让依赖关系更可控、更灵活。
高层与底层不该直接“见面”
传统写法里，业务类（如 UserService）直接 new 一个具体数据库类（如 MySQLDatabase），这就形成了强耦合：换数据库就得改业务代码，加日志或缓存也得动它。
- 高层模块关心“做什么”，比如“保存用户”；
- 底层模块负责“怎么做”，比如“用 MySQL 插入一条记录”；
- DIP 要求它们中间隔一层契约——接口，比如
Database，定义saveData()方法； - 这样
UserService只依赖Database，而MySQLDatabase和MongoDB都去实现它。
抽象是“指挥棒”，细节是“执行者”
接口本身不能被 new，也不该知道 MySQL 或 Redis 怎么连、怎么查。它的职责是声明“需要什么能力”。所有具体类反过来要服从这个声明，而不是让接口迁就某个实现。
Java Development Manual
下载
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
- 如果接口方法名改成
saveToMysql()，就违背了 DIP——抽象开始依赖细节； - 正确做法是接口只写
save(String data)，让每个实现类自己决定内部怎么落地； - 这样未来加个
RedisCacheDatabase，只要实现save()，UserService完全不用动。
依赖注入让抽象真正“活起来”
光有接口还不够，得让高层模块拿到具体的实现。Java 中常用构造器注入或 setter 注入，把实现类“塞进去”，而不是自己创建。
立即学习“Java免费学习笔记（深入）”；
-
new UserService(new MySQLDatabase())是手动注入，适合小项目； - Spring 等框架通过配置或注解自动完成注入，比如
@Autowired private Database database;； - 测试时可以轻松传入
MockDatabase，验证业务逻辑是否正确，不依赖真实数据库。
它不只是写法，而是设计思维的切换
DIP 的本质是把“谁来干”和“干什么”分清楚。高层模块定义需求（通过接口），底层模块响应需求（实现接口）。这种分工让系统更容易应对变化：
- 换技术栈？换实现类就行；
- 加新功能？新增实现类 + 少量配置；
- 单元测试？用模拟对象替换真实依赖；
- 多人协作？前端开发可基于接口先写业务逻辑，后端并行实现数据层。
