8

私は、チームのために標準化された 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 言語と同様) を提供する機能を提供しているようです。

足りないものはありますか？

4

3 に答える 3

2

上記のモジュールパターンは無意味です。あなたがしているのは、プロトタイプでコンストラクターを返すために1つのクロージャーを使用することだけです。あなたは同じことを達成することができたでしょう：

function Module() {};
Module.prototype.whatever = function() {};

var m = new Module();
m.whatever();

実際、同じ出力で、1つのオブジェクト（クロージャー）が作成されないように保存しているはずです。

モジュールパターンを使用する他のビーフは、プライベートカプセル化に使用している場合、具体的なクラスではなく、シングルトンでのみ簡単に使用できることです。プライベートデータを使用して具象クラスを作成するには、2つのクローザーをラップすることになり、醜くなります。また、アンダースコアの疑似プライベートプロパティをデバッグできる方が、表示されている方がはるかに簡単であることに同意します。「誰かがあなたのクラスを間違って使用した場合はどうなるか」という概念全体が正当化されることは決してありません。クリーンなパブリックAPIを作成し、それを文書化します。人々がそれを正しくフォローしていない場合は、チームに貧弱なプログラマーがいます。変数を非表示にするためにJavascriptで必要な作業量（Firefoxのevalで検出できます）は、中規模から大規模のプロジェクトであっても、JSを通常使用する価値はありません。人々はあなたのオブジェクトを詮索してそれらを学ぶのではなく、あなたのドキュメントを読みます。ドキュメントが優れている場合（JSDocを使用する例）、必要なすべてのサードパーティライブラリを使用するのと同じように、ドキュメントはそれに固執します。jQueryやYUIを「改ざん」することはありません。パブリックAPIを信頼して使用するだけで、その下でどのように、何を使用するかをあまり気にする必要はありません。

于 2012-08-01T13:14:14.467 に答える
2

モジュール パターンを使用してプロトタイプを作成することもできます。

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

他のポスターが言ったように、クリーンなグローバル名前空間がその理由です。ただし、これを達成する別の方法は、依存関係管理などの他の問題も解決する AMD パターンを使用することです。また、ある種のクロージャーですべてをラップします。 これは、非同期モジュール定義の略であるAMDの優れた紹介です。

また、さまざまなモジュール パターンの理由が徹底的にカバーされているため、JavaScript パターンを読むことをお勧めします。

于 2012-05-16T19:18:28.300 に答える
1

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

つまり、モジュール パターンは自己完結型のコードを促進します。モジュールは通常、1 つのオブジェクトをグローバル名前空間にプッシュし、モジュールとのすべての対話はこのオブジェクトを経由します。これは「メイン」メソッドのようなものです。

他のフレームワークや JavaScript コードとの衝突の可能性を減らすため、グローバル名前空間の混乱が少ないことは良いことです。

于 2012-05-16T19:09:31.537 に答える