DIP与DI与IoC [英] DIP vs. DI vs. IoC
问题描述
-
依赖关系反转原则。意味着您应该始终只依靠接口而不依赖于其实现。如果你的班级依赖于任何其他班级，那是坏的，因为这取决于第二类的细节。如果你的课程依赖于界面，那就完全可以，因为这种依赖只意味着你的课堂需要一些抽象的东西，可以做一些特定的事情，而且你并不关心它的做法。
由于DIP中的P代表原则，我应该以这种方式定义：依赖性反转原则是一个原则，它要求所有代码的实体只依赖于细节他们真的需要。
通过他们真正需要的细节我的意思是最简单的接口。我还使用实体一词强调，DIP也适用于程序和其他任何事情，不仅适用于课程。
-
依赖注入即可。它仅适用于启用DI的实体。启用DI的实体是一个开放用于配置其行为而不改变其内部的实体。有两种基本类型的注入（在谈论课程时）：
- 构造函数注入 - 当你通过所有必需的抽象细节
- Setter Injection - 当您在创建对象后澄清所需的方面。
因此，定义可能如下所示：依赖注入是将抽象细节传递给实际需要这些细节。
通过真正需要这些细节我的意思是接口为最简单的情况。一直以来，实体一词一直用于强调DI也适用于程序和其他任何事情。
-
反转控制。 / strong>通常将它定义为图书馆和框架之间的区别，因为以程序编程方式编写程序等等。对我来说最令人困惑的事情我相信这里的主要想法就是启动任何行动。或者你做任何事情任何时候（程序方式），或者你等待，直到有人问你（IoC的方式）。
我的定义是： IoC是您的程序执行流程的财产，只要您不执行任何操作，直到 要求您执行。
听起来完全符合好莱坞原则，但我相信好莱坞原则和IoC都是完全一样的。
我明白了吗？
我的看法是：DIP是 em>引导我们走向DI。基本上，松散耦合是目标，至少有两种方法可以实现。
- 依赖注入
- 服务定位器
但是，服务定位器是一种反模式，与DIP无关。然而，DI是DIP的正确应用程序。
BTW当谈及DI和松耦合时，我找到最适用的域驱动设计中的术语。基本上，服务是遭受DI的唯一对象 。
For about 2 months I've been reading everything I can find for these 3 topics and I'm not yet sure I got it.
Dependency Inversion Principle. Means you should always only rely on interfaces and not on their implementations. If your class depends on any other class, that's bad, because it depends on that second class' details. If your class depends on interface, that's absolutely OK since this kind of dependence only means that your class needs something abstract that can do something specific and you don't really care the way it does it.
Since P in "DIP" stands for "Principle", I should probably define it this way: Dependency Inversion Principle is a principle that requires all your code's entities to depend only on details they really need.
By "details they really need" I mean interfaces for the simplest case. I also used the word "entities" to emphasize that DIP is also applicable to procedures and whatever else, not only to classes.
Dependency Injection. It's only applicable to DI-enabled entities. DI-enabled entity is an entity which is "open" for configuring its behavior without changing its internals. There are 2 basic kinds of injection (when talking about classes):
- Constructor Injection - is when you pass all the required "abstract details" to the object just by the moment it's about to be constructed.
- Setter Injection - is when you "clarify" the required aspects after the object has already been created.
So, the definition is probably like following: Dependency Injection is a process of passing the "abstract details" to the entity that really needs these details.
By "really needs these details" I mean interfaces for the simplest case. The word "entities" is, as always, used to emphasize that DI is also applicable to procedures and whatever else.
Inversion of Control. It's often defined as "difference between libraries and frameworks", as "writing programs the either way you did in procedural programming" and so forth. That the most confusing thing for me. I believe that main idea here is just about initiating any actions. Either you do something "whenever you want" (Procedural way), or you "wait" until someone asks you (IoC way).
My Definition is: IoC is a property of your program's execution flow, when you don't do anything until they ask you to do it.
It sounds exactly as "Hollywood Principle", but I believe that "Hollywood Principle" and IoC are both absolutely the same idea.
Do I understand it?
My take on it is this: DIP is the principle that guides us towards DI. Basically, loose coupling is the goal, and there are at least two ways to achieve it.
- Dependency Injection
- Service Locator
However, Service Locator is an anti-pattern and has nothing to do with the DIP. DI, however, is the correct application of the DIP.
The relationship between DI and IoC has been explained before.
BTW, when talking about DI and loose coupling, I find the terminology laid out in Domain-Driven Design the most applicable. Basically, Services are the only kinds of objects subjected to DI.
这篇关于DIP与DI与IoC的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
