什么时候不应用依赖倒置原则？

我目前正在尝试弄清SOLID。因此，依赖倒置原则意味着任何两个类都应该通过接口而不是直接进行通信。示例：如果class A有一个方法，该方法需要一个指向类型的对象的指针class B，则该方法实际上应在一个类型为对象的对象abstract base class of B。这对打开/关闭也有帮助。

如果我理解正确，那么我的问题是将其应用于所有类交互是一种好习惯还是应该尝试从层次上考虑？

我对此表示怀疑是因为我们为遵循这一原则付出了一些代价。说，我需要实现feature Z。经过分析，我的结论是功能Z包含的功能A，B和C。我创建了一个门面类Z，即，通过接口，使用类A，B和C。我开始编码的实施，在某些时候我意识到，任务Z实际上是由功能性A，B和D。现在，我需要取消C界面，C类原型并编写单独的D界面和类。如果没有接口，则只需要替换该类。

_{换句话说，要更改某些内容，我需要更改1.调用者2.接口3.声明4.实现。在python直接耦合的实现中，我只需要更改实现。}

在许多卡通或其他媒体中，善恶的力量通常由坐在角色肩膀上的天使和恶魔来说明。在这里的故事中，我们的肩膀不是固体，而是善恶，而另一侧则是YAGNI（您将不需要它！）。

最大限度地利用SOLID原则最适合大型，复杂，超可配置的企业系统。对于更小或更具体的系统，使所有内容都变得异常灵活是不合适的，因为花费抽象的时间并不会带来好处。

例如，传递接口而不是具体的类有时意味着您可以轻松地将文件中的读取交换为网络流。然而，对于软件项目的量很大，这种灵活性是不永远会被需要，而且你可能也只是通过具体的文件类和收工和饶你的脑细胞。

对软件开发的部分了解是随着时间的流逝可能会改变什么，什么没有改变。对于可能会更改的内容，请使用界面和其他SOLID概念。对于不会用到的东西，请使用YAGNI并仅传递具体类型，忘记工厂类，忘记所有运行时连接和配置等，并忘记很多SOLID抽象。以我的经验，YAGNI方法被证明是正确的要多得多。

用外行的话来说：

应用DIP既简单又有趣。初次尝试时设计不正确还不足以完全放弃DIP。

• 通常，IDE可以帮助您进行这种重构，有些甚至可以使您从已经实现的类中提取接口。
• 几乎不可能在第一时间就完成设计
• 正常的工作流程涉及在开发的第一阶段更改和重新考虑界面
• 随着开发的发展，它日趋成熟，您将不需要太多理由来修改接口
• 在高级阶段，接口（设计）将变得成熟并且几乎不会改变
• 从那一刻起，您就可以从中受益，因为您的应用程序可以扩大规模。

另一方面，使用接口和OOD进行编程可以将乐趣带回到有时过时的编程技巧中。

有人说这增加了复杂性，但我认为反对是对的。即使是小型项目。它使测试/模拟更加容易。它使您的代码更少（如果有任何case语句或嵌套的话）ifs。它降低了圈复杂度，使您以崭新的方式思考。它使编程更类似于现实世界的设计和制造。

在有意义的地方使用依赖关系反转。

一个极端的反例是许多语言中包含的“字符串”类。它代表一个原始概念，本质上是一个字符数组。假设您可以更改此核心类，则在此处使用DI毫无意义，因为您永远不需要将内部状态换成其他内容。

如果您在模块内部使用的一组对象没有暴露给其他模块或在任何地方重复使用，则可能不值得使用DI。

我认为应该在两个地方自动使用DI：

1. 在模块设计用于扩展。如果一个模块的全部目的是扩展它并改变行为，那么从一开始就将DI引入是很有意义的。

2. 在出于代码重用目的而重构的模块中。也许您编码了一个类以执行某项操作，然后稍后意识到通过重构可以在其他地方利用该代码，因此有必要这样做。这是DI和其他可扩展性更改的理想选择。

这里的关键是在需要的地方使用它，因为它将引入额外的复杂性，并确保您通过技术要求（第一点）或定量代码审查（第二点）来衡量需求。

DI是一个很棒的工具，但就像任何*工具一样，它可能会被过度使用或滥用。

_{*以上规则的例外：往复锯是完成任何工作的理想工具。如果它不能解决您的问题，它将删除它。永久。}

在我看来，最初的问题缺少DIP的要点。

我对此表示怀疑是因为我们为遵循这一原则付出了一些代价。说，我需要实现功能Z。经过分析，我得出的结论是功能Z由功能A，B和C组成。我创建了外观类Z，该类通过接口使用类A，B和C。实现，到某个时候，我意识到任务Z实际上包含功能A，B和D。现在，我需要取消C接口，C类原型并编写单独的D接口和类。没有接口，只有类会被替换。

要真正利用DIP，您首先要创建Z类，并使其调用A，B和C类（尚未开发）的功能。这为您提供了A，B和C类的API。然后，您将创建A，B和C类，并填写详细信息。实际上，在创建类Z时，应该完全根据类Z的需要来创建所需的抽象。您甚至可以在编写A，B或C类之前就围绕Z类编写测试。

请记住，DIP曾说过：“高级模块不应依赖于低级模块。两者都应取决于抽象。”

一旦确定了Z类需要什么以及它想要获得它所需要的方式，就可以填写详细信息。当然，有时需要对Z类进行更改，但99％的情况并非如此。

永远不会有D类，因为您已经确定Z在编写之前需要A，B和C。需求的变化完全是另一回事。

简短的答案是“几乎从不”，但实际上，在一些地方，DIP毫无意义：

1. 工厂或建筑商，其工作是创建对象。这些本质上是完全包含IoC的系统中的“叶子节点”。在某些时候，某些东西必须实际创建您的对象，并且不能依靠其他任何东西来做到这一点。在许多语言中，IoC容器都可以为您做到这一点，但有时您需要采用老式的方式。

2. 数据结构和算法的实现。通常，在这些情况下，您要优化的显着特征（例如运行时间和渐近复杂性）取决于所使用的特定数据类型。如果要实现哈希表，则确实需要知道要使用的是存储数组，而不是链表，并且只有表本身知道如何正确分配数组。您也不想传递可变数组，并且让调用者通过弄乱哈希表的内容来破坏哈希表。

3. 域模型类。这些实现了您的业务逻辑，并且（大多数时候）只有一种实现才有意义，因为（大多数时候）您只为一项业务开发软件。虽然某些领域模型类可能使用其他的域模型类构造，这通常会是对案件逐案基础。由于域模型对象不包含任何可以有效地模拟的功能，因此DIP没有可测试性或可维护性。

4. 作为外部API提供且需要创建其他对象的任何对象，这些对象的实现详细信息您不希望公开公开。这属于“库设计与应用程序设计不同”的一般类别。一个库或框架可以在内部自由使用DI，但是最终将不得不做一些实际的工作，否则它不是一个非常有用的库。假设您正在开发网络库；您确实不希望使用者能够提供自己的套接字实现。您可能会在内部使用套接字的抽象，但是向调用者公开的API将创建自己的套接字。

5. 单元测试，测试加倍。伪造品和存根应该做一件事并且简单地做。如果您的假冒品非常复杂，足以担心是否要进行依赖注入，那么它可能太复杂了（也许是因为它实现的接口也太复杂了）。

可能还有更多；这些都是我一个上看到的有些频繁。

有些迹象表明您可能在无法提供价值的水平上应用DIP：

• 您有一个C / CImpl或IC / C对，并且只有该接口的一个实现
• 介面和实作中的签章一一对应（违反DRY原则）
• 您经常同时更改C和CImpl。
• C在您的项目内部，不作为库在项目外部共享。
• 您对Eclipse / Visual Studio中的F12中的F3感到沮丧，将您带到界面而不是实际的类

如果您看到的是这种情况，最好直接让Z调用C并跳过该界面，这样会更好。

另外，我不认为依赖注入/动态代理框架（Spring，Java EE）通过方法修饰来实现与真正的SOLID DIP相同的方式-这更像是方法修饰在该技术堆栈中的实现细节。Java EE社区认为这是一种改进，您不需要像以前那样使用Foo / FooImpl对（参考）。相比之下，Python支持将函数修饰作为一流的语言功能。

另请参阅此博客文章。

如果您总是反转依赖关系，那么所有依赖关系都将倒置。这意味着，如果您从带有一堆依赖关系的凌乱代码开始，那（实际上）就是那样，只是倒过来了。在这里，您会遇到一个问题，即对实现的每次更改也都需要更改其接口。

依赖关系反转的要点是您有选择地反转使事物纠结的依赖关系。从A到B再到C再到C的人仍然这样做。

结果应该是没有周期的依赖关系图-DAG。有多种 工具可以检查此属性并绘制图形。

有关更完整的说明，请参阅本文：

正确应用依赖倒置原则的本质是：

将您依赖的代码/服务/…拆分为一个接口和实现。接口使用它重新构造代码术语中的依赖关系，实现根据其底层技术来实现。

实现仍保留在原处。但是该接口现在具有不同的功能（并使用不同的术语/语言），描述了使用代码可以执行的操作。将其移动到该程序包。通过不将接口和实现放在同一包中，依赖项的（方向）从用户→实现转为实现→用户。