最近、私の頭の中に疑問が浮かびました：

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
}

長所

• テスト性の向上：someModuleES6構文を使用しても、スタブ/モックが簡単になりました。
• それはだ可能必ずしもそうとは限らないが、クライアントモジュールがまだ実装していないインタフェースにプログラムすることができるよう：DIPを尊重します。

短所

• 壊れたカプセル化：残っている主な質問は：

  では、誰が依存関係を作成/要求しますか？

• モジュールのすべてのクライアントでそれを行うことは非常に濡れているようです。
• 実際のプロジェクトで実行可能にするためには、おそらくDIコンテナーを使用する必要があります。

したがって、ここでの本当の質問は次のとおりです。

Javascript開発者が最初のアプローチに傾くのはなぜですか？

これは単なる「Javascriptの方法」ですか？

私自身はほとんどの場合このようなコードを書きます。モックライブラリを使用したテストセットアップのかなりの部分はありましたが、そうすることは常に間違っているように感じました。

何か不足していますか？

私は主にPHPプログラマーですが、この1年ほどは4つのJavaScriptチームと連絡を取り合っています。

オブジェクト指向プログラマーとして、依存性注入の原則が最善の方法のように思えますが、私はそうでないと少数のJS開発者から言われました。JSはまったく異なる世界です。

JavaScriptを使用すると、非常に単純な手法を使用してあらゆるものにモンキーパッチを適用できるため、JavaScript開発者は、より大規模なJavaScriptアプリケーションの構築方法に異なるテクノロジーを適用することを学びました。これらのほとんどは自己完結型モジュールのセットとしてビルドされ、パブリックエクスポートを通じて機能を公開し、他のユーザーが依存する関数を書き換えることができないようにモジュールの内部を隠します。

通常のアプローチは、コンストラクターをこれまでに公開するのではなく、ファクトリーラッパーを使用してオブジェクトの構築を公開することです。まったく同じ理由で、オブジェクトへのアクセス権を与えると、直接インスタンス化できます。何でも変更することができます。

モジュラー設計を利用することで、他の人が機能することを期待している機能をいじることを拒否しますが、必要なファイルのパブリックAPI、作成したAPIを通じて、モジュールをテストすることができます。