外観、工場、アダプター、橋など、かなりの数の設計パターンがあります。すべての開発者は、設計パターンを適用して日常のタスクを単純に解決し、おそらくその存在さえ知らないと考えられています。 たとえば、ファサード、工場、またはアダプターなどのパターンは、それらを検討することなく適用できます。 それらは非常に初歩的であり、問題を解決する際の論理的な結論です。 私の意見では、パターン自体は究極の解決策ではなく、典型的なタスクの一般的な解決策を提供するだけなので、最良のパターンは頭の中の脳の存在と高品質の製品を作りたいという願望です。
しかし、インターフェイスと非同期JavaScriptの世界では、これらのパターンを知って理解することで開発者の生活がはるかに容易になるため、オブザーバーとpub-subパターンの知識なしで生きることはできません。
ObserverとPub-subは、行動パターン（相互作用パターン）に関連しています。 システムのさまざまなオブジェクト間の相互作用を整理する必要がある場合に使用されます。
オブザーバー
オブザーバーは、1対多の関係にすぎません。 簡略化された形式では、このパターンは、観測対象（被験者）と観測者（観測者）で構成されます。
相互作用の概略図は次のようになります。
Subject-メソッドを実装します：監視、デタッチ、通知、取得、設定。
オブザーバー-更新メソッドを実装します。
サブジェクトには、それを聞くすべてのオブザーバーへのリンクも含まれます。オブザーバーには、サブスクライブ先のサブジェクトへのリンクが含まれます。
したがって、このパターンでは、オブジェクト間に直接接続があります。 サブジェクトはすべてのオブザーバーを知っており、それ自体で発生する変更を手動で通知し、各オブザーバーのupdateメソッドを呼び出します。 接続はobserveメソッドによって確立され、detachメソッドによって切断されます。
サブジェクトは自身の状態を自身の内部に保存し、その状態を伴うすべてのアクションはget / setメソッドを使用して実行する必要があるため、状態が変化するとnotifyメソッドが呼び出されます。 同様のスキームがEmberJsに実装されています。
オブザーバーは、かなり良い写真として表すことができます（ ここで借りています ）：
サンプル実装は、 Addy Osmani Webサイトで見つけることができます。
パブサブ
Pub-subパターンは、Observerパターンのバリエーションの1つです。 名前に基づいて、パブリッシャー（パブリッシャー）とサブスクライバー（サブスクライバー）の2つのコンポーネントがパターンで区別されます。 オブザーバーとは異なり、オブジェクト間の通信はイベントチャネル通信チャネル（イベントバス）を介して実行されます。
パブリッシャーはイベントチャネルでイベントをスローし、サブスクライバーは目的のイベントにサブスクライブし、バスでリッスンします。これにより、サブスクライバーとパブリッシャーの間に直接接続がないことが保証されます。
スケマティックPub-subとObserverとの違いは、次のように表すことができます。
したがって、Pub-subとObserverの主な区別機能は区別できます。
- オブジェクト間の直接通信の欠如
- オブジェクトは、オブジェクトの状態ではなく、イベントで互いに信号を送ります
- 異なるハンドラーで同じオブジェクトのさまざまなイベントをサブスクライブする機能
pub-subパターンの最もよく知られている実装の1つは、Backbone、AmplifyJsなどであり、DOMはある程度pub-subモデルも実装しています。
調停者
pub-subに基づいて、Mediatorパターンが構築されます。これにより、システムのさまざまなコンポーネント間の通信を確立できます。 メディエーターはシステム内のグローバルオブジェクトであり、システムのすべてのコンポーネントが認識しますが、コンポーネントはイベントのリスナーまたは別のイベントのパブリッシャーとして機能し、システムのオブジェクト間の通信を確立できます。
類推すると、Mediatorは市の電話交換機であり、加入者からの着信および発信コールを受信し、目的の加入者に厳密に到達します。 しかし、私たちが知っているように、電話ネットワークには欠点があります-新しい年には、膨大な数の通話で過負荷になり、加入者への通話の配信を停止する可能性があります。 Mediatorがイベントのフローに対応していない場合、同じことが起こります。
メディエータは、システムのさまざまなコンポーネント間に複数の単方向または双方向接続がある場合に特に役立ちます。 このパターンは、アプリケーションにシステムコンポーネント（子構成要素など）が埋め込まれているため、イベントポップアップのモデルを使用して内部から外部にコールバックを転送する必要がない場合に特に役立ちます。 イベントを発行する内部コンポーネントにMediatorを提供するだけで十分であり、他のコンポーネントはこのイベントについて学習します。
MediatorパターンはBackboneで非常にうまく実装されています-グローバルBackboneオブジェクト自体はMediatorとして使用するか、 Backbone.Eventsから継承できます。
なに？ どこ？ いつ？
各パターンを適用するタイミングと場所は全員のビジネスですが、適用する前に、それらの違いと機能を理解する必要があります。 たとえば、オブザーバーパターンはオブジェクト間の直接接続であり、オブザーバーにその状態の変化を通知します。 私の意見では、このパターンは、フォームフィールドの値の変化に対応する必要がある場合（バインディング）に、多くの入力フィールドを持つさまざまなフォームの開発に非常に適しています。
既に説明したように、Mediatorパターンは、たとえば、多くの複合要素を持つ複雑なインターフェイスなど、異種システムコンポーネント間で単方向または双方向の通信を確立する必要がある場合に役立ちます。このイベントに応じて、情報を取得するか、アクションを実行します。
読む
- Javascriptデザインパターンの学習、Addy Osmani
- デザインパターンを使用した大規模プログラミング、Eddie Burris
- コード例