Java Swing: отделение компонента пользовательского интерфейса от логического поведения - как вы к этому подходите?

Question

Что я делаю, например, в NetBeans:

• создать класс компонента пользовательского интерфейса с суффиксом типа компонента Swing, например JPanel, например MyUIWidgetJPanel
• создать класс логики / поведения для обработки поведения / логики, то есть того, что происходит при использовании компонента пользовательского интерфейса, например, нажатие кнопок внутри и т. д., MyUIWidgetLogic

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

Что вы думаете об этом? Хорошо? Bad

Что ты делаешь?

Answer 1

Я склонен использовать Шаблон модели презентации .

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

Затем вы можете связать свои входные значения с классом внутренней модели презентации, используя что-то вроде JGoodies Binding (я понимаю, что Spring RCP также хорош для этого).

Answer 2

Я нашел эту статью Как написать пользовательский компонент Swing , полезный в качестве примера использования делегата пользовательского интерфейса.

Грязные насыщенные клиенты от Chet Haase и Romain Guy широко рекомендуется для советов по визуально насыщенным клиентским приложениям.

Answer 3

Поскольку компоненты Swing взаимодействуют с помощью Events через поток диспетчеризации событий, вы, как правило, будете предоставлять реализации ActionListener интересующим вас элементам (например, JButton). Именно эти реализации ActionListener будут содержать логику, но имейте в виду, что если вы не используете многопоточность, ваш элемент пользовательского интерфейса (например, JButton) не будет реагировать, пока ваш ActionListener выполняет некоторые вычисления и удерживает контроль.

Answer 4

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

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller