2

1.I would like to know if the following structure is incorrect, what is the reason, and what is the solution for that: Assume I have implemented a client for net game The client has 2 main packages:
A.GUI - hold all the swing Jpanels etc.
B.LogicEngine

In Logic engine I have a class called clientThread which main goal is to communicate with the server to get commands to execute on the Gui Panel and also to send information back as a result of the user choices on the Gui Panels..

2.In order to do so I tend to hold reference of my main Gui panel in clientThread and vise versa, is it so wrong to do cyclic reference between two classes of different projects?

3.Is it wrong in matter of object oriented programming to execute things to be shown on the Gui from within class like client thread which is responsible in some way to manage the flow of the game although it is on logical engine package?

4.Also if the Gui part know and uses the logical part is it a problem?

Would like to hear some advices
Thank you very much

JavaSa
  • 5,813
  • 16
  • 71
  • 121
  • See also this [answer](http://stackoverflow.com/questions/2163544/re-paint-problem-on-translucent-frame-panel-component/2166500#2166500). – trashgod Sep 27 '11 at 21:59

2 Answers2

8

Obviously the GUI should depend on the engine, not the other way around (and, god forbid, they should not depend on each other).

Your problem is actually pretty common and simple to solve. The engine thread should allow client code to install a listener that will be notified every time something happens. Than GUI implements that listener and installs it. Note that the game logic engine is only aware of the listener interface, not the particular implementation that lies in your GUUI package.

This is an implementation of the Observer pattern and it has several advantages:

  • notifying code (logic) is not coupled with the "interested" code (the GUI), there is not dependency from engine to GUI
  • you can plug any implementation of listener/observer, for instance changing Swing application to console/mobile/web application without any change to the engine.
  • you can have several listeners, e.g. one to update the GUI, second one to run sound, etc.

Finally there is nothing wrong with manipulating your GUI from logic thread, hoever you must be aware of event dispatching thread.

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • Okay so, if I understood you correctly. The GUI should hold reference to the engine, but the engine should communicate with the GUI through listeners that will be installed on engine and observer in the GUI to watch out that listeners. do you have some related example for doing this, as the GUI is Swing based and read there is an option of EventListener which work good with swing, is it correct or I don't need that? – JavaSa Sep 28 '11 at 11:25
  • Swing is a good example. When you press the button Swing will run an `ActionListener` associated with it. The Swing button obviously doesn't have a dependency on your code responding to button press. Button only has a dependency on listener abstract interface, which you are implementing. In your case the engine depends on listener interface and your GUI (window, frame or any other class) implements that listener. – Tomasz Nurkiewicz Sep 28 '11 at 11:30
5
  1. I would add a third element in. I would have GUI, LogicEngine, and Communication packages. In this way, you could do testing using files, or a local database, or mock classes. Logic and sockets don't belong together. They are simply inputs and outputs of each other.
  2. I personally would have the logic know nothing about the GUI. The GUI's job would exist only to make calls into the logic. The GUI doesn't know who or what is calling into it, nor would it care. It's the same reason a microwave doesn't care if I am using it or my wife.
  3. I don't quite understand this question. Could you rephrase it?
  4. No, the other way around is the problem. The GUI exists so the user can manipulate the logic. The bad things happen when the logic depends on the GUI.
corsiKa
  • 81,495
  • 25
  • 153
  • 204