Структура кода Java Swing GUI

Question

У меня есть класс, который расширяет JFrame и формирует GUI моей программы. Я хочу использовать графический интерфейс для двух основных целей:

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

Учитывая, что в моем классе много элементов GUI, исходный файл уже довольно большой, и не похоже на хорошую практику связывать весь программный код с кодом GUI. Мне интересно, как лучше структурировать мой код? Я считаю, что существует проблема, когда требование 1 создает зависимость от графического интерфейса пользователя для программного кода, а второе требование делает противоположное.

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

Answer 1

Звучит так, будто вы ищете учебный шаблон MVC (Model-View-Controller) для учебника. Я рекомендую вам Google "Шаблон проектирования MVC" для резюме и вариантов использования. При этом, возможно, вы захотите поместить логику вашей программы в класс «Singleton» (опять же, Google «Шаблон проектирования Singleton»). Правильно реализованный Singleton должен быть доступен из любого другого класса в вашем коде.

Рассмотрим также третий средний класс, который действует исключительно для хранения данных, вы помещаете в него значения для хранения и извлекаете из него значения для работы. Теперь это создает 3 чистых сегмента для вашего кода: данные (модель), графический интерфейс (представление) и логика (контроллер). Вуаля, вы только что реализовали шаблон проектирования MVC (Model-View-Controller) ...

Answer 2

Я не уверен, что есть один «лучший» способ структурировать код GUI.Как правило, вы должны следовать MVC.Ваша программа (модель) не должна никогда напрямую зависеть от вашего кода просмотра.Что ему разрешено делать, так это уведомлять контроллер о том, что модель (или ее части) изменилась, и что в зависимости от того, какие представления в данный момент отображают, указанную часть модели следует обновить.

Swing уже предоставляет этот уровень абстракции для некоторых изего типы компонентов, большинство классов (несколько странно) с суффиксом Model.Простой пример, на который вы можете посмотреть: BoundedRangeModel.Для каждой «единицы» данных, которой управляет ваша программа, должен быть только один экземпляр такой модели, и разные представления, отображающие эти данные, должны совместно использовать этот экземпляр.Ваш бизнес-код управляет этим объектом, и всякий раз, когда этот фрагмент данных изменяется, графический пользовательский интерфейс уведомляется об этом, вызывая некоторые прослушиватели событий.

Answer 3

Бизнес-логика не должна зависеть от логики графического интерфейса.

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

Если бизнес-логика должна вызывать GUI, она должна делать это через четко определенные интерфейсы обратного вызова, не зависящие от GUI, или слушатели.Например, вы можете зарегистрировать ProgressListener на некотором объекте бизнес-логики, и этот объект будет вызывать обработчик прогресса.Графический интерфейс будет иметь реализацию ProgressListener, которая фактически обновит некоторые индикаторы выполнения или текстовую область.Но бизнес-логика зависит только от интерфейса, а не от конкретной реализации.