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是一种反模式,与DIP无关.但是,DI是DIP的正确应用.

之前已经解释过DI和IoC之间的关系.

BTW,在谈到DI和松散耦合时,我发现Domain-Driven Design中的术语最适用.基本上,服务是唯一受DI影响的对象.