0

私のシステムは、クライアントからサーブレットにオブジェクトを正常に渡します。ただし、Java 1.1に対応するために構築されているため、原始的です。渡すメッセージオブジェクトは、int(約70種類の1つを表す)と、解析する必要のあるトークンの文字列(トークンには、リスト、オブジェクトのリストなどが含まれる場合があります)で構成されます。良くない!

したがって、これをJava1.5にリファクタリングすることを検討しています。intの代わりにenumを使用することは確かに改善ですが、残りのメッセージを送信する方法がわかりません。各タイプを表すために70の異なるクラスを作成することは、確かに正しい方法ではありません。

これをリファクタリングする方法についてのアドバイスはありますか?

4

4 に答える 4

3

シリアル化されたオブジェクトを使用することをお勧めします。

これらは、ネットワークを簡単に通過できるようになっています。

あなたの状況では、シリアル化された「メッセージ」クラスが必要になります。次に、それをストリームに読み書きできます。

これは、シリアル化されたオブジェクトの使用に関するチュートリアルですそこにはたくさんあります。

于 2009-05-15T15:34:54.057 に答える
2

各タイプのメッセージを表すために異なるクラスを作成する必要はありません。必要なプロパティを使用して1つのメッセージクラスを作成します。このようなもの:

public class Message implements Serializable{
     private Long id;
     private String msgText;
     //other necessary properties

     public Message(){
        this(0, "default message");
     }

     public Message(Long id, String msgText){
         setId(id);
         setMsgText(msgText);
         //etc
     }

     //getters and setters
}

次に、必要に応じてオブジェクトを作成します。例えば:

Message m1 = new Message(9, "The Eagle has landed");
//serialize m1 to server

Message m2 = new Message(27, "The Wren has landed");
//serialize m2 to the server

等々。

于 2009-05-15T16:36:18.527 に答える
0

xStreamを使用して、オブジェクトをXMLにシリアル化し、オブジェクトに戻すこともできます。

于 2009-05-15T15:47:12.327 に答える
0

最初の質問:なぜ変更を加える必要があると感じますか?現在のシステムが、追加する予定の機能をサポートしていないためですか?それとも、掃除のために行って掃除したいだけですか?後者の場合は、眠っているバグをそのままにしておくことを強くお勧めします。

2番目の質問:これはアプレットだと思います。別のフロントエンドを使用する予定はありますか?または、このサーバーを汎用サービスとして公開しますか?いいえの場合、最初の質問に戻ります。はいの場合、ほぼ確実に、言語固有のシリアル化を避けたいと思うでしょう。

サービスとして公開することを計画している場合は、「標準」のサービスプロトコルに従うことをお勧めします。RESTは、おそらく最も簡単なPOSTingXMLペイロードです。SOAPを実行することもできますが、私は常にそのやり過ぎだと考えてきました。

または、標準のURLエンコードされたPOSTを使用することもできます。これは、すべてをXMLでラップするよりも実装が簡単なはずです。

于 2009-05-15T16:53:23.307 に答える