依赖倒置原则（DIP）要求模块依赖抽象（接口或抽象类）而非具体实现，由高层模块定义接口、外部容器（如Spring）注入具体实例，从而隔离变化、提升可测试性与可维护性。
依赖倒置原则（DIP）不是“让代码少用 new”，而是把谁决定具体类型这件事，从实现细节里抽出来，交给更稳定、更抽象的一方来控制。
依赖抽象，而不是具体实现
核心是：模块之间不直接依赖具体类，而依赖接口或抽象类。这样当具体实现变化时，调用方不用改。
- 比如日志功能，不要写
new FileLogger()或new DbLogger()，而是定义一个Logger接口，让业务类依赖它 - 具体用哪种日志方式，由外部（如配置、工厂、Spring 容器）决定，业务逻辑完全不知道也不关心
- 接口要由高层模块（稳定需求）定义，不是底层模块（易变实现）来定——避免抽象被实现牵着走
通过构造注入/方法注入解耦依赖
把具体实现的创建和使用分开。创建交给外部，使用只面向接口。
- 构造函数传入依赖是最常见、最清晰的方式：
public OrderService(Logger logger) - 避免在类内部 new 实例，也别用静态工具类强绑定（如
LogUtil.info()），那等于硬编码依赖 - 单元测试时，可直接传入 MockLogger，无需启动文件系统或数据库
结合 Spring 等框架自然落地
现代 Java 项目中，DIP 往往不靠手写工厂，而是靠 IoC 容器自动完成依赖装配。
立即学习“Java免费学习笔记（深入）”；
- 声明
@Service和@Repository，用@Autowired注入接口，Spring 自动匹配并注入具体 Bean - 切换实现只需改配置或加个
@Primary，甚至运行时通过 Profile 切换（如 dev 用 ConsoleLogger，prod 用 KafkaLogger） - 关键仍是：你的业务类里不能出现
new XxxServiceImpl()，也不能 import 具体实现类
警惕“伪抽象”和过度设计
不是所有地方都要接口+实现两层。DIP 是为应对变化，不是为抽象而抽象。
- 如果某个类确定永远只有一种实现（比如一个简单的 DTO 工具类），强行抽接口反而增加维护成本
- 接口方法要聚焦职责，别为了“看起来像抽象”堆一堆空方法，或让接口承担多个不相关的角色
- 判断标准很简单：这个依赖未来是否可能换？换了会不会影响调用方？如果答案是否定的，就先别倒置
基本上就这些。DIP 的本质不是语法技巧，而是把变化点隔离出来，让稳定的部分控制不稳定的部分。写的时候多问一句：“如果明天要换掉这个组件，我得改几处？”——改得越少，说明倒置得越到位。
