Cyclic dependencies- always wrong?

Question

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

Answer 1

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.

Answer 2

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.