1

意図せずにデザインパターンを使用したかどうかを把握しようとしていますか? ここで私を助けてください。

イベント (event1、event 2、... eventn) を生成するアプリケーションがあります。

イベント処理メソッドが記述されている別のライブラリ (イベント ハンドラ ライブラリ) があります。

イベントハンドラーライブラリによって実装された「GenerateEvent」としてメソッドを持つインターフェース（Communicator）を使用します。

最後に、イベントを生成するメイン アプリケーションは、リフレクションを使用してイベント ハンドラ ライブラリをロードし、実行時にイベント番号に基づいて、イベント固有のクラス (イベント ハンドラの) がフックされます。メイン アプリは、Interface メソッド GenerateEvent を使用してイベントを送信します。

2 つのアセンブリ間で連携するためにインターフェイスが使用されているため、これは一種のデザイン パターンですか? 説明が不十分な場合に備えて、疑似コードの観点から詳細を提供できます。

編集：追加したいのですが、イベントの結果は、別のメソッド SendResult() (イベントハンドラーからメインアプリへ) を持つコミュニケーターインターフェイスを介してメインアプリケーションに返されます。さて、この戻り機能はパターンを変更しますか? おそらく工場の設計パターンでしょうか。動的ロード (リフレクションによる) + イベントに応じたサブクラスの初期化 ??

4

3 に答える 3

0

これは、イベント生成用のObserverです。リフレクションによる動的読み込みについては不明

于 2012-08-01T07:38:21.310 に答える
0

詳細がなければ、自信を持って答えるのは難しいですが、リフレクションについて言及し、パブリッシュ/サブスクライブ モデルがあるように見えるので、オブザーバーパターンの実装であるイベント バスに似ているように聞こえます。

その記事を読むと、パブリッシュ/サブスクライブ自体がパターンとして言及されていることがわかります。そのため、どのパターンを実装したかは間違いなく議論の余地があります:)

于 2012-08-01T07:35:26.460 に答える
0

具体的な詳細がなければ、パターンを正しく使用したかどうかを結論付けるのは難しいです.ええ、他の人が言及したように、イベントベースのパブリッシャー-サブスクライバーモデルがあるように見えます.オブザーバーパターンである可能性があります. Plsはより多くの情報を提供します!!

オブザーバー/パブリッシャー-サブスクライバー パターン: オブジェクトは別のオブジェクトの特定のアクティビティをサブスクライブし、通知を受け取ります。サブスクライバーはオブザーバーとも呼ばれ、監視対象のオブジェクトはパブリッシャーまたはサブジェクトと呼ばれます。パブリッシャーは、重要なイベントが発生したときにすべてのサブスクライバーに通知 (呼び出し) し、多くの場合、イベント オブジェクトの形式でメッセージを渡します。

Communicator クラスは、イベントを生成するパブリッシャーであり、作成したイベント ハンドラー ライブラリはサブスクライバーです!!

于 2012-08-01T07:47:02.893 に答える