依赖倒置原则（DIP）是否适用于应用层内部及稳定依赖？

问题1：DIP是否适用于同一层内类之间的依赖？ #

DIP的核心是依赖抽象而非具体实现，它的适用场景从来不是只限定在层边界——同一层内只要存在职责分离的需求，就有应用DIP的价值，但绝非“必须用”。

举个领域层的例子：假设你有一个OrderValidator类，它依赖StockChecker来校验库存。如果StockChecker未来可能有不同的实现逻辑（比如普通库存校验、预售库存校验、临期商品特殊校验），哪怕都在领域层，给StockChecker定义一个抽象接口IStockChecker，让OrderValidator依赖这个接口，就能让OrderValidator不被具体校验逻辑的变更影响，同时也符合单一职责——OrderValidator只负责订单规则校验，库存校验的细节交给具体实现。

但如果是同一层内完全紧密耦合、逻辑单一且无任何变体可能的依赖（比如一个只做加减乘除的MathHelper被同一层的类调用），强行套接口纯粹是增加冗余，完全没必要。DIP不是教条，要权衡收益和成本。

问题2：DIP是否适用于不会变更实现或无多实现的依赖？ #

首先要承认：没有任何依赖是“永远不会变更”的，只是变更概率高低的问题。如果在可预见的周期内，这个依赖确实没有多实现需求，也不会有逻辑变更，那应用DIP的收益极低，甚至为负——你要维护额外的抽象层，却得不到任何实际好处。

至于有人说“用接口让测试更简单”，这其实是个过时的误区：现在主流的测试框架都支持mock具体类，不需要为了测试强行加接口。当然，如果依赖的具体类有很多非契约方法，用抽象接口可以明确依赖的契约范围，让测试更聚焦，但这属于“锦上添花”，不是必须。

总结来说：如果依赖没有多实现需求、变更概率为0，DIP对你来说没有意义；但如果只是“当前没需求”，未来有潜在变更可能，提前定义抽象接口可以降低后续重构的成本——这取决于你对业务变化的预判。

内容的提问来源于stack exchange，提问作者myol