Best design for a "Command Executer" class

Posted by Justin984 on Programmers See other posts from Programmers or by Justin984
Published on 2012-11-03T18:10:32Z Indexed on 2012/11/03 23:17 UTC
Read the original article Hit count: 229

Sorry for the vague title, I couldn't think of a way to condense the question.

I am building an application that will run as a background service and intermittently collect data about the system its running on. A second Android controller application will query the system over tcp/ip for statistics about the system.

Currently, the background service has a tcp listener class that reads/writes bytes from a socket. When data is received, it raises an event to notify the service. The service takes the bytes, feeds them into a command parser to figure out what is being requested, and then passes the parsed command to a command executer class. When the service receives a "query statistics" command, it should return statistics over the tcp/ip connection.

Currently, all of these classes are fully decoupled from each other. But in order for the command executer to return statistics, it will obviously need access to the socket somehow. For reasons I can't completely articulate, it feels wrong for the command executer to have a direct reference to the socket. I'm looking for strategies and/or design patterns I can use to return data over the socket while keeping the classes decoupled, if this is possible.

Hopefully this makes sense, please let me know if I can include any info that would make the question easier to understand.

© Programmers or respective owner

Related posts about design-patterns

Related posts about architecture