这些天来，我脑海中浮现出一个问题：

我们的Javascript方法是否与传统软件开发中被认为是好的做法的几乎所有东西背道而驰？

我有一系列与此陈述有关的问题/意见，但是为了遵守StackExchange的格式，将它们分成不同的问题会更好。

模块要求

如今的标准Javascript代码如下所示：

const someModule = require('./someModule')

module.exports = function doSomethingWithRequest() {
  // do stuff
  someModule.someFunc()
  // do other stuff
}

好处

• 封装：模块独立工作，并且知道执行其功能所需的一切。
• 作为一种颜色，客户可以更轻松地使用该模块。

缺点

• 可测试性差：在不使用DI时这是标准配置，但在动态语言（例如Javscript）中，可以通过* mockery或模块来规避* rewire。
• 它确实违反了DIP-请勿与依赖注入混淆。-因为我只能导入具体模块。
• 它可能违反了OCP-例如，假设我有一个日志模块（通过fs模块）写入文件系统。如果我想扩展此日志模块以将其发送到网络，那将非常困难。

_{*这可能与CommonJS甚至AMD模块一起使用，因为它们大部分是在用户领域实现的。但是，我不确定使用ES6 import语法怎么可能。}

依赖注入

使用依赖注入，它将更像是：

module.exports = function doSomethingWithRequest(someModule) {
  // do stuff
  someModule.someFunc()
  // do other stuff
}

好处

• 可测试性增强：现在someModule，即使使用ES6语法，也可以更轻松地进行存根/模拟。
• 这是可能兑现DIP：不一定但是，作为客户端模块仍然可以通过编程来实现的，不能的接口。

缺点

• 封装破损：剩下的主要问题是：

  好的，那么谁来创建/获取依赖关系？

• 这样做，在模块的每一个客户似乎很湿。
• 为了在实际项目中可行，这可能需要我使用DI容器。

因此，这里的真正问题是：

为什么Javascript开发人员倾向于采用第一种方法？

这仅仅是“ JavaScript方式”吗？

我自己大部分时间都是这样编写代码的。我使用模拟库分享了相当多的测试设置，但是这样做总是很不对劲。

我想念什么吗？

我主要是一名PHP程序员，但过去一年左右一直与4个JavaScript团队联系。

作为一个面向对象的程序员，依赖注入原理似乎是最好的方法，但是很少有JS开发人员告诉过我。JS是一个完全不同的世界。

由于JavaScript允许您使用非常简单的技术来猴子修补所有事物，因此JavaScript开发人员学会了如何在构建大型JavaScript应用程序方面采用另一种技术。其中大多数都是作为独立模块的集合构建的，这些模块通过公共出口来展示功能，隐藏模块的内部，以防止其他人重写您依赖的功能。

通常的方法通常是甚至不公开构造函数，而是使用工厂包装程序公开对象的构造-出于完全相同的原因：如果您授予某人访问对象的权限，则他们可以直接实例化它们允许更改任何内容。

通过利用模块化设计，您可以拒绝其他人摆弄您希望使用的功能，但是您仍然可以测试模块-通过所需文件的公共API（您创建的API）进行测试。