javascript - 依赖注入(inject)非实例化对象的优点和缺点

Question

在您看来，JavaScript 中依赖注入(inject)非实例化对象的优点和缺点是什么？

您可能想要探索的一些上下文是:

• 单元测试
  • 是否值得对它进行 dep-injecting？毕竟，即使没有 dep 注入(inject)，您也可以为每个测试覆盖对假对象的不可实例化的“静态”依赖。
• 重构
  • 定位和重构不可实例化的依赖项是否会变得更加困难？
• 可读性
  • 哪种实现方式更容易遵循？含蓄或明确对你重要吗？
• 文件大小

代码

不可实例化的对象:

WindowFactory = {
  buildWindow: function() {
     return {};
  }
};

依赖注入(inject):

(House = function(windowFactory) {
  this.windowFactory = windowFactory;
}).prototype = {
  build: function() {
    var window = this.windowFactory.buildWindow();
  }
};

var house = new House(WindowFactory);

对比非依赖注入(inject)变体:

(House = function() {
}).prototype = {
  build: function() {
    var window = WindowFactory.buildWindow();
  }
};

var house = new House();

上下文

我的主要目标是使上面的代码可测试。我陷入了外部化可实例化依赖项的习惯(例如 var window = new
window (); var house = new House(window);).这有助于当单位 -测试可实例化对象(例如 House)，因为不是真实的dependencies (Window) 我可以用一个假的 (var
假窗口 = {}; var house = new House(fakeWindow);), 而不必担心在测试我的时候冗余测试依赖项目的。 (这种形式的依赖注入(inject)在测试时也很有用依赖于通过 XHR、DOM 事件检索的某些数据的对象，sessionStorage 或 cookie。)

现在，当依赖本身是一个可实例化的对象时，好处对我来说很明显；但是当依赖是非可实例化对象(例如上面代码中的 WindowFactory)，我有关于有用性的第二个想法。

Answer 1

如果您在单元测试中有所收获，那对我来说可能已经足够了。您将能够在不依赖于全局/外部状态的情况下干净地测试功能。增加的好处就变成了可读性；您清楚地表明您在函数的参数中依赖于哪个全局状态/api。

能够在测试的设置/拆卸中更改静态方法是解决该问题的一种方法，但我个人认为它容易出错并且很麻烦。