Command Pattern - return a value

7
votes

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.

1
javacommand-pattern
Can you explain why you need to send a value back to the caller? Perhaps some more context will help. - Ocelot20
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? - rfeak
stackoverflow.com/questions/1154935/… is a similar question - nos
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 - Joeblackdev

1 Answers

4
votes

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.