13

誰かが2つの主な違いを指摘できますか?

少なくとも概念的には、この 2 つは非常に密接に関連しているようです。推測を危険にさらすとしたら、パブリッシュ/サブスクライブ メソッドはメディエーター パターンのサブセットであると言えます (メディエーターは必ずしもパブリッシュ/サブスクライブの方法で使用する必要はありませんが、後者には一種のメディエーターが必要なようです)物体）。それに近いところはありますか？

4

5 に答える 5

17

違いをどのように説明するかというと、メディエーターでは、エンド アプリケーションがメッセージを受信するかどうかを気にする可能性があるということです。したがって、これを使用して、誰がメッセージを受信して​​いるかを保証します。一方、pub/sub ではメッセージを公開するだけです。購読者がいる場合、彼らはそれを取得しますが、あなたは気にしません。

于 2010-07-01T23:07:16.733 に答える
3

実装は同じかもしれませんが、論理的には異なります (違いは単純ですが、わかりにくいです)。以下で簡単に説明していきます。

実際には、パブリッシュ/サブスクライブ パターンの実装では、メソッド「パブリッシュ」および「サブスクライブ」を持つオブジェクトが少なくとも 1 つあります。ただし、それらをさらに増やすこともできるため、コンポーネント間の通信は定義上集中化されていません。

Mediator パターンの実装では、メソッド「publish」および「subscribe」を持つオブジェクトが 1 つだけ存在します。したがって、コミュニケーションは定義上「集中型」です。

于 2013-11-12T12:39:24.287 に答える
3

このページによると、パブリッシュ/サブスクライブ モデルはメディエーター パターンの実装です。

編集

設計パターンが「パターン」と呼ばれるのは、実装ごとに違いがあるためです。それらは、人々がすでにソフトウェアをどのように書いているかについての観察の集まりであるため、法令や標準的な形式のセットではありません。したがって、設計が設計パターンに「厳密に」準拠する方法は実際にはありません。

于 2010-07-01T23:06:13.473 に答える
0

主な違いの 1 つは、問題のコンテキストにあると思います。

問題はどちらのパターンでも解決できますが、実際の問題は次のとおりです。

1: 「イベントによってどの程度の変化がもたらされるかは、一般的な状況に依存しますか?」

2: 「リスナーはどのくらいの頻度で変わると予想されますか?」

メディエーター パターンの古典的なケースは、多くのコンポーネントを含む複雑な UI があり、それぞれの更新が他の同様のコンポーネントの状態に複雑な相互依存関係を持っている場合に、これを最もよく示しています。

この問題は pub/sub パターンで解決できますが。コンポーネントがイベントをリッスンし、更新に必要なロジックが含まれている場合、コンテキスト オブジェクトは (イベントと共に) 必要なすべての情報を運びます。ここでの利点は、コンポーネント自体に関連するロジックを適切にカプセル化できることです。欠点は、そのようなコンポーネントが頻繁に変更されることが想定されている場合、導入する新しいコンポーネントごとにこのロジックを完全に複製する必要があることです。

メディエーターを使用することは、別のレイヤーを導入し、コンポーネントからさらに抽象化することです。これらのコンポーネントは表現 (UI のルック アンド フィール) のみを処理するため、より薄くなり、変更が非常に簡単になります。このアプローチで私が抱えている唯一の問題は、更新ロジックが他のコンポーネントに流出しているように見え、コンポーネントの動作も変更する場合、システムの更新でコンポーネントとメディエーターを変更する必要があることです。

これは、私たちが解決しなければならない大きなジレンマ/トレードオフです。正しくないものがある場合は、修正してください。

于 2010-12-09T06:41:03.153 に答える