Javascriptモジュールパターンの利点は何ですか？

Question

私は私のチームに標準化されたJavascriptのコーディングスタイルを提案するための研究を行っています。ほとんどのリソースは今、このような閉鎖を伴う「モジュール」のパターンをお勧めします：

var Module = function() { 

    someMethod = function() { /* ... */ }; 

    return { 
     someMethod: someMethod 
    }; 

}(); 

をしてModule.someMethod();ようにそれを呼び出します。このアプローチは、従来のOOPコンテキストで静的であるメソッド、例えばデータをフェッチ/保存するためのリポジトリクラス、外部要求を行うためのサービスレイヤなどでのみ機能するように見えます。私が何かを見逃していない限り、モジュールパターンは通常、サービスメソッドからUIグルーコードに渡す必要があるデータクラス（DTOと考える）で使用するためのものではありません。

私が引用した参照の共通の利益は、モジュールパターンとJavaScriptで真のプライベートメソッドやフィールドを持つことができるということですが、これはまた、 "静的またはインスタンスメソッドを持つことができることとともにを達成することができますこれと同様の古典」Javascriptのスタイル：

myClass = function(param) { 
    // this is completely public 
    this.publicProperty = 'Foo'; 

    // this is completely private 
    var privateProp = param; 

    // this function can access the private fields 
    // AND can be called publicly; best of both? 
    this.someMethod = function() { 
     return privateProp; 
    }; 

    // this function is private. FOR INTERNAL USE ONLY 
    function privateMethod() { 
     /* ... */ 
    }; 
} 

// this method is static and doesn't require an instance 
myClass.staticMethod = function() { /* ... */ }; 

// this method requires an instance and is the "public API" 
myClass.prototype.instanceMethod = function() { /* ... */ }; 

だから私は、私の質問は、伝統的なスタイルよりもモジュールのパターンが優れて作るものだと思いますか？それはちょっときれいですが、それはすぐに明らかな唯一の利点であるようです。実際、伝統的なスタイルは静的なメソッドのコレクションを単に返すのではなく、実際のカプセル化（JavaやC＃のような真のOOP言語に似ています）を提供する能力を提供するようです。

紛失しているものがありますか？

Answer 1

あなたはモジュールのパターンに言及するのを忘れてしまったもう一つの利点、それはつまり、人々は、彼らが言うときに参照してくださいどのような「グローバルな名前空間を汚染しない」、グローバル名前空間に少ない混乱を促進することです。確かにあなたの古典的なアプローチでそれを行うことができますが、それは無名関数の外にオブジェクトを作成することは、グローバル名前空間でそれらのオブジェクトを作成することにより容易に貸与されるようです。すなわち

、モジュールのパターンは、自己のコードを含んでいた推進。モジュールは通常、1つのオブジェクトをグローバル名前空間にプッシュし、モジュールとのすべての対話はこのオブジェクトを通過します。それは「主な」方法のようなものです。それは他のフレームワークおよびJavaScriptコードとの衝突の可能性を減らすため、グローバル名前空間で

あまり混乱は、良いです。他のポスターがきれいグローバル名前空間がその理由であると述べたよう

var Module = function() { 
    function Module() {}; 
    Module.prototype.whatever = function() {}; 
    return Module 
}(); 
var m = new Module(); 
m.whatever(); 

：

Answer 2

モジュールのパターンが表示さだけでなくプロトタイプを作成するために使用することができます。しかしこれを達成するもう1つの方法は、依存パターン管理のような他の問題も解決するAMDパターンを使用することです。それはまた、すべての種類の閉鎖でラップします。ここには、非同期モジュール定義の略であるIntroduction to AMDがあります。

それは徹底的に様々なモジュールパターンの理由をカバーしていて、私もJavaScript Patternsを読んでお勧めします。上記

Answer 3

モジュールパターンが無意味です。あなたがやっているのは、ひとつのクロージャを使ってプロトタイプのコンストラクタを返すことだけです。

実際には、1つのオブジェクト（クロージャー）が作成されずに同じ出力で保存されていたとします。モジュールパターンと

私の他の牛肉は、それはあなたがプライベートカプセル化のためにそれを使用している場合は、あなただけのシングルトンではなく具体的​​なクラスで簡単にそれを使用することができます。プライベートデータを持つ具体的なクラスを作成するには、2つのクローザーをラップしてしまいます。アンダースコアの擬似プライベートプロパティをデバッグできることは、可視になるとずっと簡単になることに同意します。 「誰かがあなたのクラスを間違って使うとどういうこと？」という考え方は、決して正当化されません。きれいな公開APIを作成し、文書化してください。人々が正しく従わないと、あなたのチームに貧しいプログラマーがいます。 （Firefoxでのevalで発見することができます）変数を非表示にするJavaScriptで必要な努力の量はさらに大規模プロジェクトへの媒体のため、JSの典型的な使用価値はありません。人々はあなたのオブジェクトを詮索してそれらを学び、彼らはあなたのドキュメントを読む。あなたのドキュメントが良ければ（JSDocの使用例）、私たちが必要とするあらゆるサードパーティのライブラリを使用するのと同じように、それに固執するでしょう。私たちはどれだけか、何それは下に使用していますあまり気にすることなく、公開APIを信頼して使用し、jQueryのか、YUIと「改ざん」はありません。