Циклические зависимости - всегда неправильно?

Question

1.Я хотел бы знать, неверна ли следующая структура, в чем причина и каков выход из этого: Предположим, я реализовал клиент для сетевой игры У клиента есть 2 основных пакета:
A.GUI - удерживайте все поворотные панели и т. Д.
B.LogicEngine

В движке логики у меня есть класс clientThread, основной целью которого является взаимодействие с сервером для получения команд для выполнения на панели графического интерфейса, а также для отправки информации обратно в результате выбора пользователя на панелях графического интерфейса.

2. Для этого я склонен хранить ссылку на мою основную панель графического интерфейса в clientThread и наоборот, так ли неправильно делать циклическую ссылку между двумя классами разных проектов?

3. Неправильно ли в объектно-ориентированном программировании выполнять вещи, которые будут отображаться в графическом интерфейсе, изнутри класса, например клиентского потока, который каким-то образом отвечает за управление потоком игры, хотя он находится в пакете логического движка?

4. Также, если часть Gui знает и использует логическую часть, это проблема?

Хотелось бы услышать несколько советов
Большое спасибо

Answer 1

Очевидно, что графический интерфейс должен зависеть от движка, а не наоборот (и, не дай бог, они не должны зависеть друг от друга).

Ваша проблема на самом деле довольно распространена и проста для решения.Поток движка должен позволять клиентскому коду устанавливать прослушиватель, который будет уведомляться каждый раз, когда что-то происходит.Чем GUI реализует этот слушатель и устанавливает его.Обратите внимание, что игровой логический движок знает только интерфейс слушателя, а не конкретную реализацию, которая находится в вашем пакете GUUI.

Это реализация шаблона Observer , и он имеет несколько преимуществ:

• код уведомления (логика) не связан с "заинтересованным" кодом (GUI), нет зависимости от движка для GUI
• Вы можете подключить любую реализацию слушателя/ Наблюдатель, например, сменив приложение Swing на консольное / мобильное / веб-приложение без каких-либо изменений в движке.
• у вас может быть несколько слушателей, например, один для обновления графического интерфейса пользователя, второй для запуска звука и т. д.

Наконец, нет ничего плохого в манипулировании вашим GUI из логического потока, однако вы должны знать о потоке диспетчеризации событий .

Answer 2

1. Я бы добавил третий элемент. У меня были бы пакеты GUI, LogicEngine и Communication. Таким образом, вы можете проводить тестирование с использованием файлов, локальной базы данных или фиктивных классов. Логика и сокеты не принадлежат друг другу. Это просто входы и выходы друг друга.
2. Лично мне бы логика ничего не знала о GUI. Работа графического интерфейса будет существовать только для вызова логики. Графический интерфейс не знает, кто или что вызывает в нем, и не будет заботиться. По той же причине микроволновка не заботится о том, использую ли я ее или мою жену.
3. Я не совсем понимаю этот вопрос. Не могли бы вы перефразировать это?
4. Нет, проблема в другом. GUI существует, поэтому пользователь может манипулировать логикой. Плохие вещи случаются, когда логика зависит от графического интерфейса.