views:

374

answers:

4

My system successfully passes objects from a client to servlet. However it is primitive as it was built to cater for Java 1.1. The message object it passes consists of an int (representing one of about seventy types) and a String of tokens which need to be parsed (the tokens may contain a list, a list of objects, etc). Not good!

So, I'm looking to refactor this to Java 1.5. Using an enum instead of an int is certainly an improvement, but I'm unsure how to send the rest of the message. Creating seventy different classes to represent each type surely isn't the correct way to go.

Any pointers on how I should refactor this?

+3  A: 

You may want to use serialized objects.

They are meant to be easily passed along the network.

In your situation you will just need a serialized 'message' class. Then you can read and write it to a stream.

Here is a tutorial on using serialized objects. There are lots out there.

jjnguy
+1 because it's the right concept. unfortuntely, on Java most serializers are XML-based...
Javier
Java has built in serialization that can serialize regular objects. No need for XML.
jjnguy
Thanks, but even with serializing and deserializing I'd still need to create a class for each type of message sent. Basically I guess the question I'm trying to ask is how to send an arbitrary number of different messages without creating a class for each new type of message.
Pool
Why don't you do something with a dictionary or list of parameters in the message. You can determine the type of message by the int, and then you know which parameters you need to pull out of a message.
jjnguy
A: 

You can also serialize the objects to XML and back to objects again using xStream.

Mike Pone
+2  A: 

There is no need to create a different class to represent each type of message. You create one message class with the properties that you need. Something like this:

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
}

And you then create objects as needed. For example:

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

and so on.

Vincent Ramdhanie
A: 

First question: why do you feel the need to make changes? Is it because the current system doesn't support some feature that you're planning to add? Or do you just want to go in and clean up for the sake of cleaning? If the latter, I'd strongly suggest leaving sleeping bugs lie.

Second question: I'm assuming this is an applet. Will you ever plan to use a different front end? Or expose this server as a generic service? If no, then I come back to the first question. If yes, then you almost certainly want to keep away from a language-specific serialization.

If you are planning to expose as a service, then following some "standard" service protocol is a good idea. REST is probably the easiest, POST-ing XML payloads. You could also do SOAP, but I've always considered that overkill.

Or, you could go with a standard URL-encoded POST ... which should be easier to implement than wrapping everything in XML.

kdgregory