How do I respond to incoming network messages in a way that achieves loose coupling?

Question

I'm working on a client-server sort of protocol right now in Ruby. I've hit a snag where I'm not entirely sure how to proceed. Currently, I have a class, Remote that signifies a remote connection (for use through EventMachine). When Remote receives a message (i.e, network packet), it sends it off to the MessageDecoder, which returns the decoded message in a hash, like so (pseudo-code ahead)

{ source = <the_remote_connection>,
  message_code = 1, // An operation code that indicates how to respond to this message
  payload = {
    packet_specific_key = packet_specific_value // provided by the decoder
  }
}

So, when I get this back from MessageDecoder, the Remote ships it off to its ConnectionListener, which needs to decide how to distribute that message across the application. Here's the issue: Each message might require a different scope of variables. For example, one might require the instance of a World object that the ConnectionListener doesn't know about (and rightfully shouldn't - the network code should not be coupled to the rest of the program)

So my question is: how can I implement a loosely-coupled system for distributing the reception of network-ignorant messages from a remote connection in my application that somehow magically retains scopes?

EDIT: For comments, example.

Let's assume I have a World object. The World knows about the entities within it - rocks, trees, you get the general idea. So, a command comes in from the Remote saying :DestroyRock - which should invoke World#destroy_rock. The World should not know where the command to :DestroyRock comes from. It should just know that World#destroy_rock was invoked on it.

The issue is, I need some way of finding a middle-man between ConnectionListener and World#destroy_rock. ConnectionListener definitely should not be aware of the World object, because if it is, that means I've now coupled my network code to my gameplay logic.. woops. That's pretty bad.

Answer 1

The ConnectionListener has to know about the World instance, because it needs to pass it the command. The ConnectionListener is already a middle man, adding another middle man won't solve anything. It should, however, only know it by interface. ICommandable or something. This would provide a method to pass the message to and return appropriate response, possibly an even to provide asynchronous response/message to client and possibly a filter which messages this object should handle.

Than in the initialization code you'll create the World instance and the ConnectionListener instance and register the world with the listener. Something like:

listener.addCommandable(world);

the filter probably makes more sense here than inside the object, so perhaps

listener.addCommandable(':DestroyRock', world);

(or with a list of commands or something).

I might also make sense to implement the interface not in the World object itself, but in an adaptor, so the World object does not need to know about the format of the command from network. Especially if there are other ways to send it commands like a stand-alone version that has both user interface and the engine in one process and does not use network.

Of course since Ruby is dynamically typed, an "interface" is just a documented set of methods.