17370845950

依赖倒置原则（DIP）要求模块依赖抽象（接口或抽象类）而非具体实现，由高层模块定义接口、外部容器（如Spring）注入具体实例，从而隔离变化、提升可测试性与可维护性。

依赖倒置原则（DIP）不是“让代码少用 new”，而是把谁决定具体类型这件事，从实现细节里抽出来，交给更稳定、更抽象的一方来控制。

依赖抽象，而不是具体实现

核心是：模块之间不直接依赖具体类，而依赖接口或抽象类。这样当具体实现变化时，调用方不用改。

• 比如日志功能，不要写 new FileLogger() 或 new DbLogger()，而是定义一个 Logger 接口，让业务类依赖它
• 具体用哪种日志方式，由外部（如配置、工厂、Spring 容器）决定，业务逻辑完全不知道也不关心
• 接口要由高层模块（稳定需求）定义，不是底层模块（易变实现）来定——避免抽象被实现牵着走

通过构造注入/方法注入解耦依赖

把具体实现的创建和使用分开。创建交给外部，使用只面向接口。

• 构造函数传入依赖是最常见、最清晰的方式：public OrderService(Logger logger)
• 避免在类内部 new 实例，也别用静态工具类强绑定（如 LogUtil.info()），那等于硬编码依赖
• 单元测试时，可直接传入 MockLogger，无需启动文件系统或数据库

结合 Spring 等框架自然落地

现代 Java 项目中，DIP 往往不靠手写工厂，而是靠 IoC 容器自动完成依赖装配。

• 声明 @Service 和 @Repository，用 @Autowired 注入接口，Spring 自动匹配并注入具体 Bean
• 切换实现只需改配置或加个 @Primary，甚至运行时通过 Profile 切换（如 dev 用 ConsoleLogger，prod 用 KafkaLogger）
• 关键仍是：你的业务类里不能出现 new XxxServiceImpl()，也不能 import 具体实现类

警惕“伪抽象”和过度设计

不是所有地方都要接口+实现两层。DIP 是为应对变化，不是为抽象而抽象。

• 如果某个类确定永远只有一种实现（比如一个简单的 DTO 工具类），强行抽接口反而增加维护成本
• 接口方法要聚焦职责，别为了“看起来像抽象”堆一堆空方法，或让接口承担多个不相关的角色
• 判断标准很简单：这个依赖未来是否可能换？换了会不会影响调用方？如果答案是否定的，就先别倒置

基本上就这些。DIP 的本质不是语法技巧，而是把变化点隔离出来，让稳定的部分控制不稳定的部分。写的时候多问一句：“如果明天要换掉这个组件，我得改几处？”——改得越少，说明倒置得越到位。