I want to create a game that will work both locally and online.
My first thought was to create an interface that would have all the methods that will be needed by the GUI for the business logic and then have a network implementation and a local implementation.
This works fine for request-response messages. But what about messages that the server sends, where I have to update some GUI components (i.e. JLabels)?
My first solution to this was to implement listeners, where each change in the implementation will fire an event. The GUI would register and change it's components appropriately. However, calls to fire events in the business logic looks a little wrong.
Am I in the right track? Because I think I'm not. Any suggestions?
Thank you.
NOTE: The client is a simple Java Swing GUI.
What you have described will serve the goal of keeping the model independent of presentation issues, which is A Good Thing. This will also help you during design, development, and maintenance of the model, because you can write unit tests on the basis that certain changes in the model should fire specific events, without worrying about what that might look like on a screen.
And, of course, it frees you up to have different GUI designs for different environments.
The key is that the events should be about changes in the state of the model, and not about intended actions/representations at the presentation level. Let the presentation layer deal with whether/how to respond to a model event.