DIP vs. DI与IoC

Question

大约2个月我一直在阅读这三个主题我能找到的所有内容，我还不确定是否已经找到了。

1. 依赖性倒置原则。意味着你应该始终只依赖于接口而不是它们的实现。如果你的班级依赖于任何其他班级，这是不好的，因为它取决于第二类的细节。如果你的类依赖于接口，那绝对可以，因为这种依赖只意味着你的类需要一些抽象的东西，它可以做一些特定的东西而你并不关心它的做法。

   由于“DIP”中的P代表“原理”，我应该用这种方式定义：依赖性倒置原则是一个原则，要求所有代码的实体仅依赖于它们真正的细节需要。

   通过“他们真正需要的细节”我指的是最简单案例的界面。我还使用“实体”一词来强调DIP也适用于程序和其他任何内容，而不仅仅适用于类。

2. 依赖注入。它仅适用于启用DI的实体。启用DI的实体是一个“开放”的实体，用于配置其行为而不更改其内部。有两种基本的注射方式（谈论课时）：

   • 构造函数注入 - 就是当您将所有必需的“抽象细节”传递给对象时，就在它即将构建的那一刻。
   • Setter Injection - 在您创建对象后“澄清”所需方面。

   因此，定义可能如下：依赖注入是将“抽象细节”传递给真正需要这些细节的实体的过程。

   “真的需要这些细节”我指的是最简单的情况下的界​​面。 “实体”这个词一如既往地用来强调DI也适用于程序和其他任何东西。

3. 控制反转。它通常被定义为“库和框架之间的差异”，“以程序编程中的任何一种方式编写程序”等等。这对我来说是最令人困惑的事情。我认为这里的主要想法只是启动任何行动。要么“随时随地”（程序方式）做某事，要么“等”直到有人问你（IoC方式）。

   我的定义是： IoC是程序执行流程的属性，当您他们要求您执行此操作时，您不执行任何操作。

   这听起来与“好莱坞原则”完全一样，但我相信“好莱坞原则”和IoC都是完全相同的想法。

我理解吗？

Answer 1

我对此的看法是：DIP是指导我们走向DI的原则。基本上，松散耦合是目标，并且至少有两种方法可以实现它。

• 依赖注入
• 服务定位器

然而，Service Locator is an anti-pattern并与DIP无关。但是，DI是DIP的正确应用。

relationship between DI and IoC has been explained before。

BTW，在谈到DI和松散耦合时，我发现Domain-Driven Design中列出的术语最适用。基本上，Services are the only kinds of objects subjected to DI。

Answer 2

我的20c，开始编码。你可能至少对它是如何工作有一个大概的了解。编写概念证明（POC）将是一种很好的方式，可以看到事物如何融合在一起并在开发和运行时工作。阅读只会带你到目前为止，这样做真的有助于点击它。

如果您不知道从哪里开始，大多数关于DI的博客文章都有简单的示例，您可以运行。不要陷入使用哪个框架（Unity，Spring，Castle Windsor等），因为它对于POC来说无关紧要。