3

次のシナリオがあります。

キューからメッセージを読み取る QueueReader クラスがあります。また、EmailSender や SMSSender などの送信者もいくつかあり、これらのメッセージは、それぞれ電子メールまたは SMS を使用してクライアントに送信されます。将来的には、さらに多くの送信者が追加される可能性があります。

これを行うには 2 つの方法が考えられますが、どちらがより有益かはわかりません。

工場パターン:

SenderFactory を使用して適切な送信者を作成し、その Send() メソッドを呼び出す SenderManager を作成できます。

したがって、メッセージを読み取るときに QueueReader は、次のことを行う SenderManager の Send() を呼び出します。

IMySender sender = SenderFactory.CreateSender()
sender.Send()

//I have the information to create the proper Dispatcher in the 
//factory based upon the message but I have omitted it for brevity.

したがって、新しい送信者を追加する必要がある場合でも、QueueReader または SenderManager を変更する必要はありません。新しい Sender を追加し、SenderFactory を変更します。

オブザーバー パターン 上記とは対照的に、QueueReader クラスに NewMessage のイベントを実装させることができます。次に、すべての送信者にこのイベントをサブスクライブさせます。送信者は、上記のファクトリーにあった情報にアクセスして、メッセージが自分宛てのものかどうかを知ることができます。

これの利点は、新しい Sender がイベントをサブスクライブするだけで済むことです。

これをすべて書き留めたので、オブザーバーパターンがよりクリーンなアプローチだと思います...

ただし、誰かが洞察や提案を持っている場合は、共有してください。

ありがとう！

4

2 に答える 2

3

私はハイブリッドアプローチを使用します：

SenderManager (オブザーバー) は受信メッセージをリッスンし、適切な送信者を選択します (または、必要に応じて SenderFactory に作成を依頼します)。これには 2 つの利点があります。

まず、ManInTheMiddle タイプの攻撃を回避して、選択する送信者を制御できます (SenderManager クラスを公開する必要はありません)。これは、他の開発者が独自のセンダーを実装できるように API を公開する場合に特に重要です。

第 2 に、インスタンス化された複数の送信者を用意して何もせずにストリームを監視する代わりに、一種のガベージ コレクターを実装し、不要になった送信者を破棄できます。

SenderManger に対して送信者を登録するには、何らかの登録機能が必要です。

ObserverPattern を使用する場合は、不要なメッセージを処理するために、デフォルトの送信者 (ログ システムの場合もあります) を実装することを忘れないでください。

于 2012-06-02T07:03:12.183 に答える
0

特定の基準に基づいてインスタンスを作成する場合は、ファクトリ パターンで十分です。

SMS または電子メールの送信者を使用することが確実な場合は、依存性注入の使用も検討し、任意の DI コンテナーを使用して実行時に IMySender を解決できるようにすることができます。たとえば、StructureMapです。

オブザーバーのパターンについてはよくわかりませんが、少し複雑なようです。

于 2012-06-02T07:02:24.313 に答える