c++ - 依赖注入(inject)的要点是将依赖传递给目标函数(或构造函数)而不是在目标内部创建它们吗？

Question

刚刚完成 AngularJS 类(class)，到处都在使用依赖注入(inject)这个术语。我说得对吗？它的要点是:将依赖对象传递给目标函数(或构造函数)而不是在目标内部创建它们？

我得到了它的好处，易于单元测试等。但我一直在其他领域这样做，主要是 c++ 和 googlemock，不知道有一个术语依赖注入(inject)。那我错过了什么吗？我想 Angular 的 DI 必须管理这些服务和工厂的生命周期，并将它们传递给请求对象，但这应该是实现细节而不是依赖注入(inject)概念的一部分？

Answer 1

“依赖注入(inject)”并没有什么特别神奇的地方，但它是保持责任隔离和依赖灵活的有用模型。改进的可测试性是一个令人愉快的副作用，但依赖注入(inject)的核心只是局部和单一职责原则的特定体现。

这是一个典型的 C++ 示例。首先，考虑类 Foo 是如何有机增长的:

class Foo
{
 public:
    Foo(A a, B b, C c)
    : a_(a), widget_(b, c) {}

 private:
    A a_;
    Widget widget_;
 };

Foo 的功能可能需要一些Widget 类型的内部对象。但请注意 widget_ 对象的构造(以及潜在的失败!)是如何由 Foo 的构造函数负责的。我们不仅需要通过 Foo 传递所有需要的参数，相反，Foo 还需要处理 Widget 的所有潜在故障模式> 构造函数。最重要的是，我们只能使用单一版本的 Widget(并且我们需要在 Foo< 中传递所有 Widget 的定义 翻译单元)。

进入依赖注入(inject):

struct AbstractWidget { ~AbstractWidget() = default; };

class Foo
{
public:
    Foo(A a, std::unique_ptr<AbstractWidget> widget)
    : a_(a), widget_(std::move(widget)) {}

private:
    A a_;
    std::unique_ptr<AbstractWidget> widget_;
};

现在 Foo 对抽象“小部件”功能的依赖性被构造函数注入(inject)到 Foo 对象中。小部件对象已经完全构建并以我们不再关心的方式运行。 Foo 现在只做一件事。一个流行的助记符是“依赖于抽象，而不是具体化”。

乍一看，这就是它的全部内容。

某些语言(例如 Java，可能还有 JavaScript)中的依赖注入(inject)是众所周知的，并且在这些语言中的教学更为突出，因为存在强大的框架来自动构建使用 DI 的设计。这种自动化可能包括相关构造函数的自动定义，并且它们可能使“注入(inject)”点远离构造的实例，这使得运行程序中的最终有效依赖性比人们预期的动态得多一个典型的 C++ 程序。