依赖注入不可实例化对象的优缺点答案

【问题标题】：Advantages & Disadvantages of Dependency-Injecting Non-Instantiable Objects依赖注入不可实例化对象的优缺点
【发布时间】：2011-03-13 08:50:55
【问题描述】：

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

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

单元测试
- 值得深度注入吗？毕竟，即使没有 dep-injection，您也可以将不可实例化的“静态”依赖项覆盖到每个测试的假对象。
重构
- 定位和重构不可实例化的依赖是否会变得更加困难？
可读性
- 哪种实现更容易遵循？隐性或显性对您来说重要吗？
文件大小

代码

不可实例化的对象：

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

依赖注入：

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

var house = new House(WindowFactory);

对比非依赖注入变体：

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

var house = new House();

上下文

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

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

【问题讨论】：

标签： javascript unit-testing dependency-injection refactoring

【解决方案1】：

如果您在单元测试中有所收获，那对我来说可能绰绰有余。您将能够干净地测试功能，而无需依赖全局/外部状态。额外的好处就是可读性；您在函数的参数中清楚地显示了您依赖的全局状态/api。

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

【讨论】：