GUI-слой vs Code layer vs Swing

Question

Я всегда кодировал консольные приложения и изучал основные навыки UML/шаблонов, используя C++.

Теперь я решил перейти на Java и добавить графические интерфейсы в свои программы.

Первый вопрос - как обрабатывать слой GUI в программе. Я имею в виду, как я должен отделить весь код GUI (добавление компонентов, обработку основных событий) с кодом, который действительно выполняет задание (например, при нажатии какой-либо кнопки).

Другой вопрос, связанный с этим по EDT. Я читал, что (почти) все компоненты Swing должны запускаться в одном и том же потоке (обычно EDT) из-за того, что они не являются потокобезопасными. Поэтому я подумал, что если «тяжелый код» вызывается из (например) ActionListener, тогда графический интерфейс перестанет быть нерешенным в течение некоторого времени, пока не закончится «тяжелый код».

Это очень нежелательно, поэтому я считаю, что естественным решением является выполнение тяжелого кода, возможно, в другом потоке или что-то подобное (я знаю, что это нужно делать осторожно, потому что я не мог больше предположить, что после пользователь нажал кнопку, «глубокое действие» выполняется перед обращением к другому графическому интерфейсу).

Итак, как вы видите, у меня есть много вопросов о том, как включить графический интерфейс в мои шаблоны, чтобы сохранить все совершенно независимые и легко поддерживаемые; и некоторые вопросы о конкретных вещах компонентов Swing и отзывчивости.

Answer 1

Отделив бизнес-логику от GUI: Если вы собираетесь использовать Swing, прежде всего изучите Model-View-Controller design pattern. Это хорошая модель для разделения проблем, и Swing полагается на нее в значительной степени.

Re сверхпрочный код и EDT: используйте , или даже лучше, SwingWorkers.

Answer 2

Вы найдете Swing, уже сильно структурированный в вариант MVC, который они называют делегатом view.
Что вам нужно сделать, так это решить, сколько логики приложений входит в слой графического интерфейса, и всегда есть что-то. Одна вещь, которая помогает, заключается в том, что если действие gui предназначено для выполнения важной задачи - например, обновление некоторых данных в базе данных, то убедитесь, что есть простой вызов, который может вызвать обработчик действий GUI, который не имеет ничего общего с gui код/​​структура. Это можно выполнить с помощью проектов в вашей среде IDE, которые имеют одностороннюю зависимость. Например, сохраните весь свой графический интерфейс в проекте «gui», который зависит от вашего «общего» проекта. «Общий» проект сможет выполнять бизнес-логику, но не импортирует виджеты виджета и не может видеть ваш проект «gui».

Хорошо, что вы определили EDT как проблему ключевого дизайна - потому что это так. SwingWorker уже был предложен LBT, что является хорошим способом управления долговременными задачами gui в отдельном потоке.