How to maintain view logic separation with a server

Question

I am writing a client server application. I wanted to fully separate the server logic, from the view. The first thing I wanted to to, is to make a sort of a message log.

The server itself should not know if the messages will be shown at a GUI, or on the console.

What I was thinking, would be to have a handler method, that would be called every time a new message was posted. So a GUI app would have it's own method to maybe add to a listView, while the console would have a simple printf.

Is there a better way to do this?

Answer 1

You're on the right track and more or less describing the Adapter Design Pattern, which is defined by wikipedia as:

Adapter design pattern is used when you want two different classes with incompatible interfaces to work together. Interfaces may be incompatible but the inner functionality should suit the need. The Adapter pattern allows otherwise incompatible classes to work together by converting the interface of one class into an interface expected by the clients.

In your case, you would probably have a GUI adapter and a Console adapter, both which would consume handle the server messages as appropriate for their user interface and you would instantiate at run-time whichever adapter is most appropriate.

• Bartlomiej Lewandowski: what about making a ServerClass with an empty onReceiveMessage function that will be overriden by a ServerGUI and SererConsole subclasses?
• Michael Lang: That doesn't sound like its decoupled like you want it and also seems to be suggestive of doing on the server side, not the client side. What you should be thinking about is the server's API independently of how its results are digested by the clients. Then you write the clients to consume that API. These days, I write servers that consume JSON and reply with JSON, so if you're thinking in these restrictive terms, you'll probably more readily see the natural decoupling points for your client/server.