ホームページ > 記事 > ウェブフロントエンド > JavaScript 設計におけるファサード モードとメディエーター モードの違いの詳細な例
ファサード モードは、この記事のアーキテクチャで重要な役割を果たします。このモードは、多くの JavaScript ライブラリまたはフレームワークに反映されており、特定の実装を隠すために高レベルの API を組み込むことです。これは、内部実装コードを簡単に変更および更新できることも意味します。たとえば、今日は jQuery を使用して実装し、明日は YUI に変更したい場合、これは非常に便利です。便利。 。
次の例は、多くのプライベート メソッドを提供し、その後、外部の世界が内部メソッドを実行および呼び出しできるようにするための単純な API を公開することを示しています。ファサードは既存の機能のみを提供しますが、メディエーターは新しい機能を追加できます。
メディエーターモード
メディエーターは、プログラム内に複数のモジュールがあり、各モジュールに依存関係を持たせたくない場合に使用され、メディエーター モードを通じて集中制御の目的を達成できます。実際のシナリオでも、メディエーターは、やりたくない多くのモジュールをカプセル化し、メディエーターを介して接続できるようにすると同時に、疎結合にするため、メディエーターを介して通信する必要があります。
メディエーター モードの利点は何ですか?これがデカップリングです。オブザーバー パターンをよく理解していれば、次の図は高レベルのメディエーター パターン図を理解するのが比較的簡単です。はパブリッシャーであり、メディエーターはパブリッシャーでもありサブスクライバーでもあります。 モジュール 1 は、何かを行う必要があることをメディエーターにブロードキャストします。メディエーターはメッセージをキャプチャした後、メッセージの処理に使用する必要があるモジュール 2 をすぐに開始します。モジュール 2 の処理が完了すると、情報がメディエーターに返されます。
同時に、メディエーターはモジュール 3 も開始し、モジュール 2 から返されたメッセージを受信すると、自動的にモジュール 3 にログを記録します。ご覧のとおり、モジュール間に通信はありません。また、メディエーターは実装することもできます。各モジュールのステータスを監視する機能。たとえば、モジュール 3 に問題が発生した場合、Mediator は一時的に他のモジュールのみを考慮し、モジュール 3 を再起動して実行を続行します。 振り返ってみると、Mediator の利点は次のとおりです。疎結合されたモジュールは同じ Mediator によって制御されるだけであり、モジュール間で直接連絡する必要はありません。情報が取得されると、複数のモジュールを処理に使用できるため、将来的に既存の制御ロジックに新しいモジュールを均一に追加することも容易になります。確かに: すべてのモジュールが直接通信できないため、パフォーマンスが若干低下する可能性がありますが、それだけの価値はあると思います。
上記の説明に基づいて簡単なデモを作成します:var module = (function () { var _private = { i: 5, get: function () { console.log('current value:' + this.i); }, set: function (val) { this.i = val; }, run: function () { console.log('running'); }, jump: function () { console.log('jumping'); } }; return { facade: function (args) { _private.set(args.val); _private.get(); if (args.run) { _private.run(); } } } } ()); module.facade({run:true, val:10}); //outputs current value: 10, running次に、それぞれ呼び出される 2 つのモジュールがあります:
var mediator = (function(){ var subscribe = function(channel, fn){ if (!mediator.channels[channel]) mediator.channels[channel] = []; mediator.channels[channel].push({ context: this, callback: fn }); return this; }, publish = function(channel){ if (!mediator.channels[channel]) return false; var args = Array.prototype.slice.call(arguments, 1); for (var i = 0, l = mediator.channels[channel].length; i < l; i++) { var subscription = mediator.channels[channel][i]; subscription.callback.apply(subscription.context, args); } return this; }; return { channels: {}, publish: publish, subscribe: subscribe, installTo: function(obj){ obj.subscribe = subscribe; obj.publish = publish; } }; }());
アプリケーション ファサード: アプリケーションのコアの抽象化
ファサードはアプリケーションコアの抽象化として機能し、メディエーターとモジュール間の通信を担当します。各モジュールはこのファサードを通じてのみプログラムコアと通信できます。抽象化として、責任は、送信ボックス コントローラーの役割と同様に、一貫したインターフェイス (一貫したインターフェイス) が常にこれらのモジュールに提供されることを保証することです。すべてのモジュールコンポーネントはメディエータを介して通信するため、ファサードは信頼性が高く、モジュールにインターフェイスを提供する機能として、セキュリティ制御という別の役割も果たす必要があります。これは、モジュールがプログラムのどの部分にアクセスできるかを決定します。モジュール コンポーネントは独自のメソッドのみを呼び出すことができ、未承認のコンテンツにはアクセスできません。たとえば、モジュールが dataValidationCompletedWriteToDB をブロードキャストする場合、ここでのセキュリティ チェックでは、モジュールがデータベースへの書き込み権限を持っていることを確認する必要があります。
アプリケーションメディエーター: アプリケーションのコア
メディエーターは、アプリケーションの中核的な役割として機能します。彼の責任について簡単に説明します。コアの仕事は、モジュールのライフサイクルを管理することです。このコアが受信した情報を取得したときに、プログラムがそれをどのように処理するかを決定する必要があります。つまり、どのモジュールを開始または停止するかを決定する必要があります。モジュールが開始されるとき、アプリケーション コアがモジュールを実行するかどうか (たとえば、DOM の準備ができたときに実行するかどうか) を決定することなく、自動的に実行できる必要があるため、モジュール自体が決定する必要があります。 どのような状況でモジュールが停止するのかという疑問がまだあるかもしれません。プログラムがモジュールの障害またはエラーの発生を検出した場合、プログラムは、コンポーネントを再起動できるように、モジュール内のメソッドの実行を継続しないように決定する必要があります。その主な目的は、ユーザーの操作性を向上させることです。経験。 さらに、コアは他の機能に影響を与えることなく、モジュールを動的に追加または削除できる必要があります。一般的な例としては、ページの読み込み開始時にはモジュールが利用可能ではないが、Gmail のチャット機能と同様に、ユーザーの操作後にモジュールが動的に読み込まれて実行される必要があることがパフォーマンス最適化の観点から挙げられます。とても良いです。 例外エラー処理もアプリケーション コアによって処理されます。また、各モジュールが情報をブロードキャストするときに、すべてのエラーもコアにブロードキャストされるため、プログラム コアは状況に応じてこれらのモジュールを停止/再起動できます。これは、疎結合アーキテクチャの重要な部分でもあり、メディエーターを介してパブリッシュ/サブスクライブを使用することで、モジュールを手動で変更する必要がありません。
以上がJavaScript 設計におけるファサード モードとメディエーター モードの違いの詳細な例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。