Observerパターン、パブリッシュ/サブスクライブの違いは何ですか?、およびData Binding?
Stack Overflowを少し検索したところ、良い答えは見つかりませんでした。
私が信じるようになったのは、データバインディングは一般的な用語であり、ObserverパターンやPub/Subパターンなど、それを実装するさまざまな方法があるということです。 Observerパターンでは、ObservableはそのObserverを更新します。 Pub/Subでは、0個のパブリッシャーが特定のクラスのメッセージを発行でき、0個のサブスクライバーが特定のクラスのメッセージをサブスクライブできます。
「データバインディング」を実装する他のパターンはありますか?
ここに3つについての私の見解があります:
基本的に、これは単に「オブジェクトYのプロパティXの値がオブジェクトBのプロパティAの値に意味的にバインドされていることを意味します。YがオブジェクトBの変更を認識または変更する方法についての仮定はありません。
オブジェクトに特定のイベントを他の人に通知する機能を付与するデザインパターン。通常、実際のイベントを使用して行われます。実際のイベントは、特定の関数/メソッドの形状を持つオブジェクトのスロットのようなものです。オブザーバブルは通知を提供するものであり、オブザーバーはそれらの通知を受け取ります。 .netでは、オブザーバブルはイベントを公開でき、オブザーバーは「イベントハンドラー」型のフックを使用してそのイベントをサブスクライブします。通知が発生する特定のメカニズムや、1つのオブザーバブルが通知できるオブザーバーの数については想定されていません。
Observable/Observerパターンの別の名前(おそらく「ブロードキャスト」セマンティクス)。これは通常、「動的」フレーバーを意味します。オブザーバーは通知をサブスクライブまたはサブスクライブ解除でき、1つのオブザーバブルは複数のオブザーバーに「叫ぶ」ことができます。 .NETでは、イベントはMulticastDelegateの形式であるため、このために標準イベントを使用できます。したがって、複数のサブスクライバーへのイベントの配信をサポートし、サブスクリプションの解除もサポートできます。 Pub/Subは特定のコンテキストでわずかに異なる意味を持ち、通常はイベントとイベンターの間に「匿名性」を伴います。これは、通常、すべてを知っている「中間者」(メッセージキューなど)しかし、個々の当事者はお互いを知りません。
多くの「MVCのような」パターンでは、observableは特定のプロパティの変更に関する情報も含む「プロパティ変更通知」の何らかの方法を公開します。オブザーバーは暗黙的であり、通常はフレームワークによって作成され、オブジェクトとプロパティを明確に識別するためのバインディング構文を介してこれらの通知をサブスクライブし、「イベントハンドラー」は新しい値をコピーし、更新または更新ロジックをトリガーする可能性があります。
データバインディングの代替実装?わかりました、ここに愚かなものがあります:
Observer/ObservableとPublisher/Subscriberのパターンには2つの大きな違いがあります。
Observer/Observableパターンは、主にsynchronousで実装されています。何らかのイベントが発生したときのすべてのオブザーバーのメソッド。 Publisher/Subscriberパターンは、ほとんどの場合asynchronous方法(メッセージキューを使用)で実装されます。
Observer/Observableパターンでは、observerはobservableを認識しています。一方、パブリッシャー/サブスクライバーでは、パブリッシャーとサブスクライバーお互いを知る必要はありません 。彼らは単にメッセージキューの助けを借りて通信します。
正しく述べたように、データバインディングは一般的な用語であり、Observer/ObservableまたはPublisher/Subscriberメソッドを使用して実装できます。データはパブリッシャー/サブスクライバーです。
ここでの答えはすべて、具体的な例を挙げずに、ObserverパターンとPub/Subパターンの微妙な違いを説明しようとしていたので、少し面白がっています。ほとんどの読者は、一方が同期でもう一方が非同期であることを読み取ることで、それぞれを実装する方法をまだ知らないに違いない。
注意すべきことは次のとおりです。これらのパターンの目標は、コードを分離しようとすることです
オブザーバーは、オブジェクト(サブジェクトと呼ばれる)がそれに依存するオブジェクトのリスト(オブザーバー)を保持し、状態の変更を自動的に通知する設計パターンです。
つまり、observable object
には、observers
(通常は関数)をすべて保持するリストがあります。そして、このリストをたどって、都合のよいときにこれらの関数を呼び出すことができます。
詳細については、 このオブザーバーパターン の例を参照してください。
このパターンは、オブジェクトのデータ変更をリッスンし、それに応じて他のUIビューを更新する場合に適しています。
ただし、短所はObservablesは、observersを保持するために1つの配列のみを保持します(例では、配列はobserversList
です)。
更新は、その配列に格納されているすべての関数をトリガーするnotify function
を1つしか持たないため、トリガーされる方法を区別しません。
異なるイベントに基づいてオブザーバーハンドラーをグループ化する場合。 observersList
をObject
のように変更するだけです
var events = {
"event1": [handler1, handler2],
"event2": [handler3]
}
詳細については、 このpubsubの例 を参照してください。
人々はこのバリエーションをpub/sub
と呼びます。したがって、発行したevents
に基づいてさまざまな機能をトリガーできます。
私は両方のパターンに関するあなたの結論に同意しますが、私にとっては、同じプロセスにいるときはObservableを使用し、プロセス間シナリオではPub/Subを使用します。 。
私は他のパターンを知らないか、このように言ってみましょう。このタスクに別のパターンは必要ありません。ほとんどのMVCフレームワークとデータバインディングの実装でさえ、通常は内部的にオブザーバーの概念を使用します。
プロセス間通信に興味がある場合は、以下をお勧めします。
「エンタープライズ統合パターン:メッセージングソリューションの設計、構築、および展開」-http:// www。 addison-wesley.de/9780321200686.html
この本には、プロセス間通信タスクでも使用できるプロセスまたはクラス間でメッセージを送信する方法に関する多くのアイデアが含まれています(より疎結合の方法でプログラミングするのに役立ちました)。
これがお役に立てば幸いです!