3

ソケット接続を待っているマルチスレッド サーバーがあります。

メッセージの最初の交換は常に同じタイプであり、クライアントは認証の詳細 (userid/pwd) を含むオブジェクトを送信し、サーバーはそれをチェックして、認証が成功したかどうかをサーバーに返信します。

この最初のメッセージ交換の後、クライアントは、サーバーが実行できるさまざまなタスクに対応するいくつかの要求を送信します。これらの不均一な要求をどのようにモデル化しますか? 特に、私の質問は、InputObjecStream/OutputObjectStream を使用してクライアントとサーバーの間で送信されるオブジェクトのタイプに関するものです。

私には2つのアイデアがありました：

  1. 2 つの属性を持つ「ジェネリック メッセージ」オブジェクトを使用します: タスク識別子と、ジェネリックなしの HashMap で、タスクの実行に要求されたさまざまなタイプのパラメーターを運ぶことができます。

  2. すべてのタイプのタスクのオブジェクト。このソリューションは「よりクリーン」ですが、受信したメッセージのタイプをサーバーに理解させる方法がわかりません。クライアントから受信したメッセージの一連のオブジェクトキャストについて考えました多くの CastException を無視して、考えられるすべての「特定のタスク メッセージ」。悪いように聞こえますが、これを回避する方法はありますか？

4

3 に答える 3

2

2つのアイデアを組み合わせてみませんか

サーバーが何をすべきか、または今反応するかを決定するためにサーバーがキャストできる共通レベルのインターフェースから始めます。

オブジェクトがリクエストの処理を担当するハンドラーに渡されると、オブジェクトをさらにキャストできます（より深いレベルのインターフェイス実装に基づく）

私見では

于 2012-08-25T08:53:13.903 に答える
1

最初のアプローチは非常に一般的ですが、維持するのは難しいでしょう。しばらくすると、この汎用マップにどのような種類のオブジェクトが含まれるべきかを思い出せなくなったことに気付くでしょう。辞書の同期を維持する必要があります。

2番目のアプローチははるかに優れています。Request基本的に、さまざまなサブクラスを持つ抽象オブジェクトを受け取ります。基本クラスは、いくつかの一般的な情報を保持できます。通常、ポリモーフィズムを使用して各サブクラスにアクションを実装し、Requestクラスの抽象メソッドをオーバーライドします。ただし、リクエストオブジェクトはサーバー側のロジックを保持する必要があるため、これはできません。

ここでできる最善のことは、 デザインパターンです。これを使用すると、コードを少しわかりにくくするという代償を払って、非常に一般的で安全な設計を実現できます。instanceofしばらくすると醜くなる傾向があります。

于 2012-08-25T08:54:13.177 に答える
0

できることはXML、コミュニケーションにメッセージを使用することです。最初のバイトXMLにメッセージをマップする必要があるオブジェクトの指示を追加し、メッセージの受信時にこれらのバイトをチェックしてインジケーターを見つけ、残りのバイトシーケンスを使用してバイトを XML オブジェクトにマーシャリングすることができます ( or または or or anyotherJAXBをSimpleXML使用DOM) xml パーサー) XML は非常に冗長なので、ここで使用してメッセージをカプセル化できます。

于 2012-08-25T09:08:49.867 に答える