问题标签 [dependency-inversion]

我有以下界面

以及以下实现

在运行时，查询列表被加载到应用程序中。每个查询都包含有关执行查询频率的信息、有关何时为查询触发警报的信息以及有关警报发生时向谁发送电子邮件的电子邮件信息（或者如果未设置，则警报应仅写入事件日志） . 我如何在运行时使用依赖注入来知道要创建什么 ISender 实例（EmailSender 或 EventLogSender），如果他们选择使用电子邮件通知而不是事件日志通知，还如何为查询更新适当的电子邮件设置？**注意：查询可以有不同的通知方式，1 可以是偶数日志通知，而其他的可以都是电子邮件。

我知道你不能创建一个 100% 遵守依赖倒置原则的程序。我们所有人都在我们的程序中通过实例化字符串来违反它而不考虑它。由于 String 是一个类而不是数据类型，我们总是依赖于一个具体的类。

我想知道是否有任何解决方案（纯理论上）。由于 String 几乎是一个几乎没有“泄漏”的黑匣子，并且具有复杂的背景算法，因此我不希望实际实现 ofcourse :)

我无法弄清楚依赖倒置原则（SOLID 原则之一）和一般的“代码到接口”或分离接口模式之间的区别。他们都主张创建一个抽象层来解耦低层和高层模块。

DI 原则设想创建接口以在较高层和较低层模块之间进行交互，但也坚持接口必须是较高层包的一部分。
为什么这应该是更高级别而不是更低级别的一部分？暴露其行为的是较低级别，所以解耦接口不应该是较低级别的一部分吗？如果有多个更高级别的模块依赖于相同的较低级别怎么办？

不然的话，
为什么不做一个单独的包来放置所有的接口，这样高层和低层都可以使用呢？（这是由分离接口模式设想的。）

我的困境是，我无法弄清楚它们的相对用途和好处。

请不要引用 Derek Greer 或 Robert Martin 的文章。我已经阅读了这些文章，但困惑仍然存在。

我设法理解了依赖注入的概念，但我根本看不到依赖反转发生在哪里。

例如，这个类具有紧密的依赖关系。

但是当应用 DI 概念时，它有点变成了这样：

但是，无论是什么情况，Man仍然会依赖于Food，所以我在这里看不到依赖关系的反转。

唯一的区别是谁放在Food他的桌子上。

所以我请你给我说清楚，倒置原则在哪里以及如何应用？

如果我想使用 DIP 开发一个假设的模块化 C++ 项目。由于模块化，我选择在一个库中完全实现一项特定功能A。另一个库B（或两个，或三个......）正在使用此功能（例如日志记录机制）：

我应该把这个接口放在哪里？一些博主似乎建议，因为接口属于它的用户（因为 DIP）你应该把接口放在用户端（或这里）。这也将提高可测试性，因为您不需要将任何实现链接到测试。

这意味着库 A 本身不会编译，因为它缺少接口。这也意味着，如果库 C 也将使用日志记录工具，它还将引入一个接口ILogger，这将破坏ODR？！这可以通过引入一个仅包含接口的额外包层库 D 来解决。但主要问题仍然存在：

接口放在哪里？我阅读了有关 DIP 的原始论文，但我不同意这种解释，即我不应该将接口放入库中。我有一种感觉，这篇论文旨在作为如何思考开发的指南（因为“用户定义的是接口而不是实现者”）。这个对吗？你如何使用依赖倒置原则？

在这篇博文中，这张励志海报描述了依赖倒置原则：

我不明白海报的意思：将灯直接焊接到墙上如何违反依赖倒置原则以及插头如何遵循依赖倒置原则。也许一些关于灯和电源插座的骨架 Java 或 C# 代码可能会有所帮助。

几个月来我一直在摸不着头脑，但我仍然能够令人满意地说服自己我有正确的答案。我们有一个非常典型的情况，即我们的应用程序的多个层之间存在依赖关系，其中每一层都在自己的程序集中。例如，我们的应用程序层使用存储库层来检索非常标准的数据。我的问题是，抽象（在这种情况下为接口）将存在于哪里，为什么？在给出的示例中，它应该进入应用程序层还是存储库层或单独的抽象程序集？

根据The Clean Architecture 描述中的图表和描述（不是我们特别遵守的），我将它们放在应用程序层中，以便所有依赖项都指向内部，但我不确定这是否正确。我已经阅读了很多其他文章并查看了无数示例，但是关于抽象应该存在于何处的推理方式却很少。

我见过这个问题，但我不相信它回答了我的问题，除非实际答案当然是没关系。

我正在学习设计模式和它周围的东西（特别是SOLID和依赖倒置原则），看起来我失去了一些东西：

遵循DIP规则，我应该能够通过不在类中创建对象（组合）而是将对象引用/指针发送到类构造函数（聚合）来使类不那么脆弱。但这意味着我必须在其他地方创建一个实例：所以一个具有聚合的类越灵活，另一个就越脆弱。

请解释我哪里错了。

如果我希望我的代码遵循 SOLID 原则，特别是依赖倒置原则，这是否意味着我必须为每个模块创建一个接口（抽象），即使它只有一个实现？

在我看来，根据这些帖子：

http://josdejong.com/blog/2015/01/06/code-reuse/

http://blog.ploeh.dk/2010/12/02/Interfacesarenotabstractions/

为每个模块创建一个“抽象”是一种代码混乱，违反了 YAGNI 原则。

我的经验法则是：不要使用依赖注入，或者为模块创建接口，除非它有多个实现（第二个实现可能是一个模拟类，用于在数据库/服务器/文件模块的情况下进行单元测试）。

有人可以帮我解决这个问题吗？SOLID 是否意味着我必须注入每个模块并对其进行抽象？如果是的话，这不是很多我们根本不会在大多数时候使用的杂物吗？

我一直在这里阅读有关解决软件设计中的循环依赖的不同答案，但我仍然无法理解。请帮助我理解它。

假设我有 A 类和 B 类，它们相互调用方法：

类根据单一职责原则完美划分。

看起来我不能在这里应用依赖倒置原则，因为我只能将一个类聚合到另一个类中。

根据最佳设计实践，你能建议我如何处理这个问题的正确方法吗？

我会很感激你用一些代码回答。