dependency-injection - 依赖注入(inject)究竟是如何减少耦合的？

Question

我已经阅读了大量关于依赖注入(inject)的内容，但我不知道它实际上是如何减少耦合的？

我对 DI 的类比是所有组件都注册到一个容器中，所以它们就像一个百宝箱。要获得一个组件，你显然首先要注册它，但随后你必须询问百宝箱(这就像一层间接)。这是正确的比喻吗？但是，“注入(inject)”是如何发生的并不清楚(这与这个类比如何？)。

谢谢

Answer 1

依赖注入(inject)(DI)本身并不会减少耦合，因为依赖依赖的组件仍然耦合到它的依赖。然而，DI 确实完成的是从组件本身移除查找依赖项的责任，并将该责任放在其他地方。

依赖 DI 的组件在依赖关系方面是完全被动的。组件中没有代码显示“创建此依赖项的新实例”或“出去为我获取此依赖项”。依赖项被赋予(注入(inject))组件，通常是在组件本身由其他对象创建时。

这种创建(或要求创建)依赖项的责任倒置称为控制反转(IoC)。

那么，如果组件不知道如何创建或请求依赖项，那么该责任在哪里呢？通常在专门为依赖解析创建的对象中，通常称为 IoC 容器。用你的比喻来说，这是你的“百宝箱”。 IoC 容器包含的指令基本上是说“当有人要求这个时，给他们其中一个。IoC 容器通常可以检查它被要求创建的组件，找出它的依赖项是什么，然后创建它们，沿着“依赖链”，直到解决所有依赖关系。

在决定“谁可以向容器询问组件的依赖项”时，思维的重大转变，即注入(inject)出现了？没有 DI，将是组件本身向容器询问其依赖项。然而，使用 DI，责任要求容器“解决”组件的依赖关系属于创建或使用组件的任何人。创建组件时，无论创建它的人都有责任提供所有依赖项。组件不知道也不关心它们如何被创造，只是他们是。

现在，如果将依赖项定义为具体实现，则组件仍然与该具体具体实现紧密耦合，即使它正在被注入(inject)。从这个意义上说，DI 本身并没有减少耦合。但是，如果将依赖项定义为接口(interface)，则组件不关心或知 Prop 体实现是什么，也不知道它是如何创建的。它仍然与依赖项耦合，但它是一种非常松散的耦合。

从这个意义上说，“依赖注入(inject)”和“接口(interface)编程”结合起来创建了非常松散耦合、高度灵活的组件。