Command Pattern - return a value

Question

I'm using the command pattern for passing a command from a client to a server via a TCP/IP socket. The server will take the command object, deserialize it and then call execute() on the command object. However, I need to pass a value back to the caller over the socket. Does the command pattern allow for this? If not, is there a work around? I have looked at the light switch example on wikipedia, which is great, but there are no return values. Any advice greatly appreciated.

Roadability

Can you explain why you need to send a value back to the caller? Perhaps some more context will help. – Derm

I'm a big believer in patterns. However, they should only be used for what they were designed for. My perception of the value of command pattern doesn't seem to match what you have described, so far. Could you expand upon what you think the command pattern buys for you in your implementation and why you are using it? – Got

#1155435 is a similar question – Verdie

Hi guys. Well, ultimately I'm looking to implement message passing between a client and server over a socket. When the client wants to invoke a method on the server, it will send a 'NetworkRequest' instance. In this will be an enum indicating the method that is to be invoked on the other side along with some parameters. There are cases where the a 'NetworkReply' will be sent back to the client with information for it to act upon. Thanks – Roadability

Answer 1

You should not have an "execute()" method on the Command sent to the remote server, this is bad in lots of ways, especially in Java. The Command should represent the action the recipient should take. Which in this case is to call a method on some object.

The Command Pattern is to represent actions taken or to be taken, not the implementation of those actions. Think more of a set of instructions to be carried out.

What your are describing is basically an over-engineer RPC call mechanism. Don't re-invent this wheel. Looks at existing RPC mechanisms, there are plenty to choose from in the Java world. Then you need to decide if the RPC is synchronous or asynchronous.

A REST based API is what is popular and will last longer as an API than any native language specific mechanism like RMI.

Paramagnetic

Good point. Do you think RMI would be a good fit for this scenario as opposed to sockets within the context of my problem? RMI will give me stubs that can be invoked directly by the client no? This seems like a much nicer approach. Thanks again for the pointers. – Roadability

I've just discovered that RMI is a no-go with android. Any other suggestions? Thanks again – Roadability

A simple REST based API is what is in vogue now days. And I don't mean RPC over HTTP, I mean real REST. -> vertigrated.com/blog/2009/10/this-isnt-rest-this-is-rpc – Paramagnetic

yea, de-serializing a Java object on Android would not have worked either, Android doesn't use the Java Virtual Machine it isn't byte-code compatible in any way. – Paramagnetic

Really? I never knew that. So to summarize - If I serialize a java object on Android, send it to a server which sends back another serialized java object, I WILL NOT be able to use the object that will be deserialized on the android device? So, HTTP REST is the best way to approach this? – Roadability

Android uses Java as a language, NOT as a runtime, it uses a completely different runtime virtual machine. -> en.wikipedia.org/wiki/Dalvik_%28software%29 – Paramagnetic

Whether serialization on Android is compatible to the "normal" Java one is independent on the VM - it is only dependent on the ObjectOutputStream and ObjectInputStream implementations (specifications, really). I see no reason to assume that the format would be a different one, as long as your class exists on both platforms and uses only (serializable) classes existing on both ones. Serialization does not use Java bytecode. – Heeltap