“控制反转”、“依赖反转”之间的区别和“解耦”
我正在阅读有关依赖倒置和解耦的理论，但我看不出两者之间的区别。
依赖倒置谈论解耦功能组件，以便较高级别的组件不依赖于较低级别的组件。
解耦讨论的是同一件事以及如何实现它。但随后我们的 IoC 容器让事情变得更加混乱。为什么它们不被称为“依赖倒置容器”或者更好的“依赖注入容器”，因为它们提供独立组件的运行时耦合？
然后我们有控制反转。它与依赖倒置基本上是一样的，不是吗？为什么有三个术语描述同一事物？还是我瞎了？
- 三者有什么区别？
- IoC 在 IoC 容器中需要做什么？
I'm reading theory about dependency inversion and decoupling and I can't see the difference between the two.
Dependency inversion talks about decoupling functional components so that higher level components don't depend on lower level components.
Decoupling talks about the same thing and how to achieve it. But then we have IoC Containers that mess things up even further. Why aren't they rather called Dependency Inversion Containers or even better Dependency Injection Containers, because they serve runtime coupling of independent components?
Then we have Inversion of Control. It's basically the same thing as Dependency Inversion isn't it? Why are there three terms that describe the same thing? Or am I blind?
- What is the difference between the three?
- What does IoC have to do in IoC Containers?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
解耦是一个非常普遍的原则，适用于许多领域。 依赖倒置是一种特定的解耦形式，您可以通过将系统的较高级别与较低级别分离到库中并使用接口来将它们解耦。这使您可以更换系统的较低级别部分，而无需进行重大返工。
例如，可以使用 IoC 容器来解耦对象的创建方式，而不是系统的较高级别部分创建较低级别类的具体实例。
控制反转是框架库使用的一种设计原则，允许框架从应用程序重新获得一些控制权。即，当某些用户界面事件发生时，窗口框架可以回调应用程序代码。马丁·福勒 (Martin Fowler) 使用“好莱坞原则”一词，如“不要打电话给我们，我们会打电话给您”。解耦是控制反转的重要组成部分。
但是IoC 容器与控制反转有什么关系呢？ 引用 Martin Fowler：
（请注意，Martin Fowler 谈论的是依赖注入，而不是依赖倒置。）
IoC 容器有助于实现依赖注入，也许更好的术语是依赖注入容器。然而，IoC 容器的名称似乎仍然存在。依赖注入是依赖反转的一个重要组成部分，但是使用 IoC 容器进行依赖注入可能会令人困惑，因为控制反转是一个更广泛、更通用的原则。
您指出命名不太一致，但这不应令人感到意外，因为这些术语是独立发明和使用的，即使它们重叠。
Decoupling is a very general principle applicable in many fields. Dependency inversion is a specific form of decoupling where you decouple the higher levels of your system from the lower levels by separating them into libraries and using interfaces. This allows you to replace lower level parts of your system without major rework.
For example, instead of the higher level parts of the system creating concrete instances of the lower level classes, an IoC container can be used to decouple how objects are created.
Inversion of control is a design principle used by framework libraries that allow the framework to regain some control from the application. I.e., a windowing framework may call back into application code when certain user interface events occur. Martin Fowler uses the term Hollywood Principle as in Don't call us, we'll call you. Decoupling is an important part of inversion of control.
But what has an IoC container to do with inversion of control? To quote Martin Fowler:
(Note that Martin Fowler talks about dependency injection, not dependency inversion.)
An IoC container helps to implement dependency injection and perhaps a better term would be dependency injection container. However, the IoC container name seems to stick. Dependency injection is an important component in dependency inversion, but the use of IoC containers for dependency injection can be confusing as inversion of control is a broader and more generic principle.
You point out that the naming isn't very consistent but that shouldn't be a big surprise as these terms have been independently invented and used even though they overlap.
依赖注入使用控制反转实现解耦。
Dependency Injection achieves Decoupling using Inversion of Control.
我从 martinfowler.com 上的 DIP in the Wild 文章中找到了以下解释，很容易理解（这里 DI = 依赖注入，DIP = 依赖反转原理，IoC = 控制反转）：
I find the following explanation from DIP in the Wild article on martinfowler.com straightforward to understand (here DI = Dependency Injection, DIP = Dependency Inversion Principle, IoC = Inversion of Control):
依赖倒置：依赖于抽象，而不是具体。
控制反转：主要与抽象，以及主要如何成为系统的粘合剂。
这些是一些讨论此问题的好帖子：
https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt -avoid-it/
https: //coderstower.com/2019/04/02/main-and-abstraction-the-de Coupled-peers/
https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/
Dependency inversion: Depend on abstractions, not on concretions.
Inversion of control: Main vs Abstraction, and how the Main is the glue of the systems.
These are some good posts talking about this:
https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/
https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/
https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/