1

便利そうに見えるのでメディエーター オブジェクトに興味がありますが、そのオブジェクトと対話してビルドする方法を学ぶためにコード例を解読することは、私を逃れます。どんなに短くても、いくつかの説明が付いているコード例が大好きです。メディエーター オブジェクトを作成するときに、私が作成しているものを説明できる人はいますか?

メディエーター オブジェクトは、クラス間で送信されるアクション イベントを処理する手段になりますか? それとも、メディエーター オブジェクトは、類似コードを 1 つの便利な場所に統合するのに適していますか?

利便性のために実用的なのか、それとも他の方法がないために実用的なのかはわかりません。詳細は、「馬鹿げた」とはいえ、最も優れています。前もって感謝します。

4

1 に答える 1

3

メディエータ オブジェクトは、それ自体は何もしないように意図されています。何らかの多重化/逆多重化 (1 つのオブジェクトが同じメッセージを他の複数のオブジェクトに送信する場合) を除いて、既に持っているロジックをその中に移動しないでください。メディエーターは単なる外部インターフェイス (同時にファサードとして機能する場合) であり、既存のオブジェクト間のメッセージ パッシング チャネルであることは間違いありません。

同様に、メディエーターは、そのようなメッセージ パッシング チャネルの必要性を認識するまで作成しないでください。そのような必要性はどのように見えますか?ますます複雑な方法で相互に呼び出しを開始するオブジェクトのセットが既にあります。これらのオブジェクトは相互への参照を格納しています。そのような参照の数は、そのようなオブジェクト自体の数よりもすでに大きくなっています。

したがって、各オブジェクトが各オブジェクトと対話する代わりに (二次数の参照と相互作用の複雑なグラフを使用して)、スター トポロジーを相互作用に導入します。誰もがメディエーターに直接話しかけます。これにより、インスタンス化、監視、デバッグ、拡張、多形化が容易になります...

メディエーターの導入を開始する時期が早すぎると、全体的な複雑さが低下するどころか増大します。

于 2013-03-22T07:51:29.383 に答える