Каковы ваши лучшие образцы дизайна и подсказки Swing?

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

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

Каковы ваши лучшие советы по дизайну GUI приложения и какие шаблоны вы используете при разработке или рефакторинге приложения GUI?

Ответ 1

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

Ответ 2

Никогда не выходите из JDialog, JFrame или JInternalFrame для определения ваших форм, диалогов...

Скорее получаются из JPanel. Это принесет вам следующие преимущества:

возможность более позднего изменения с Например, JFrame для JDialog (потому что пользователь передумал)
вы можете повторно использовать один экземпляр панели из одного JDialog в другой (JDialog обычно не используются повторно, потому что они построены со ссылкой на их "родительский", кадр или другой диалог).
вы можете позже заменить JDialog с более функциональным подкласс из сторонней структуры.

Ответ 3

Избегайте использования графических дизайнеров (строителей). Позже он сделает ваш код намного чище и проще в обслуживании.

Ответ 4

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

Ответ 5

mvc - ваш друг.

Ответ 6

Это более абстрактный ответ высокого уровня о том, что представляет ваш графический интерфейс, а не о его механизме.

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

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

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

Я взял диаграмму, заново создал ее с помощью графики (просто простой чертеж линии по большей части, но он показал оба конца и соединения между ними), а затем использовал области графики для представления элементов управления и обратной связи ( изменения цвета). Вы могли визуально видеть, что сигнал выходит. Когда вы включили loopback в дальнем конце, вы могли видеть, что линия зациклировала сигнал обратно на исходящую линию, тогда вы можете увидеть изменение цвета, поскольку ваш ближний конец начал получать шаблон, который он отправил на другую линию.

"Элементы управления" были значительно более сложными, чем это, но графический интерфейс уменьшил его до ТОЧНОСТИ, что клиенту нужно было понять проблему.

После этого у нас были клиенты, возвращающиеся к нам, говорящие нам, что они никогда не могли понять этот материал раньше, но теперь они полностью получают его!

Эта презентация была бесконечно более важной, чем проводка реализации GUI.

Ответ 7

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

Ответ 8

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

Ответ 9

Внимательно используйте шаблон MVC. Вот простой пример того, что я имею в виду:

class Person
{
  String firstName;
  String lastName;
  // and getters and setters...
}

class PersonSwingModel
{
  private Person person;
  private javax.swing.text.PlainDocument firstName;
  private javax.swing.text.PlainDocument lastName;
  // and getters and setters...
  // Create some method like init() that initializes PlainDocument values
  // to attributes in model.
}

class SavePersonAction extends AbstractAction
{
  private PersonSwingModel model;
  // and getters and setters...
}

class PersonSwingView extends JFrame
{
  private PersonSwingModel model;
  private javax.swing.JTextField firstName;
  private javax.swing.JTextField lastName;
  private SavePersonAction savePersonAction; // hook up to JButton/JMenuItem
  // and getters and setters...
  // Create some method like init() which binds PlainDocument to JTextField
  // and Actions to JButtons or JMenuItems
}

Я вижу, что некоторые люди не согласны с расширением JFrame или JPanel. Я не. Работает для меня.

Кроме того, используйте LayoutManagers. GridBagLayout очень мощный. Если вы используете его, определите некоторые константы GridBagConstraints (например, LABEL_GBC и FIELD_GBC) и продолжайте их повторное использование.

Ответ 10

Karsten Lentzsch JGoodies очень помог мне в архитектурном дизайне, особенно в отношении шаблона модели представления, привязок и проверки. Проверьте его articles и libraries.
Используйте шаблон, подобный MVC. Я говорю "нравится", потому что цель состоит в том, чтобы отделить представление от модели, а не соответствовать конкретному вкусу MVC. Я предпочитаю использовать Модель представления.
MiGLayout - я использую его для всех, если только основной менеджер макета не сделает.
Модулизуйте и повторно используйте столько, сколько сможете.
WindowBuilder Pro для Eclipse - лучший визуальный дизайнер, потому что он работает с существующим/отредактированным кодом и не блокирует вас. Теперь! У меня нет проблем с использованием дизайнеров, потому что представление должно быть отделено от остальной части кода.
Платформа Netbeans (RCP) - единственная реальная среда Swing. Я надеюсь научиться и использовать это, когда у меня есть время, потому что часть рамочной задачи - это проблемы, подобные вашим.
JavaBuilders - Прохладный проект, который разрешает декларативные пользовательские интерфейсы, но я не уверен, что он достаточно зрелый, чтобы рисковать, особенно с существующим проект. Однако интересно прочитать их книгу в формате PDF, если только понять проблемы, которые они пытаются решить.

Ответ 11

Не пытайтесь закодировать текст в своем приложении. Swing guis можно легко записать, чтобы управлять данными, подумайте об определении своего графического интерфейса в XML файле (включая имена компонентов и позиции/атрибуты макета).

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

Если вы решите использовать построитель GUI, никогда не изменяйте код, который он выводит, если вы можете его избежать - лучше привязать его к GUI из внешнего класса. Подумайте о том, что произойдет, если вам нужно сделать это без строителя - будет ли трудно порт? Невозможно?

Поймите gotchas в swing - только измените компоненты GUI из потока AWT, как можно быстрее верните поток AWT (создайте новый поток, если вам нужно сделать что-нибудь, что занимает более 100 мс),

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

Если ваши данные основаны на свойствах, серьезно подумайте о создании механизма привязки для привязки ваших элементов управления к вашим данным. Хорошей целью для DRY-кода будет 0 (ZERO) управляемых контуром строк кода для каждого элемента управления, чтобы получить часть данных из вашей базы данных в ваш графический интерфейс, попросите пользователя отредактировать ее и вернуть ее в свою БД. Это означает, что вы должны иметь возможность добавлять новый элемент управления, ничего не делая, кроме изменения ваших данных.

Ответ 12

Избегайте наследовать, когда состав будет проще.

Например, я много видел:

public class CustomerSupportApp extends JFrame { 
     JList<Customer> customers;
     OtherBusinessComponent importantComponent;

     etc. etc

}

Это смешение бизнес-логики с презентацией. Это только делает изменения от трудных до невозможных.

Лучше:

public class CustomerSupportApp { 
     JList<Customer> customers;
     OtherBusinessComponent importantComponent;
     // The app HAS-A frame but not IS-A frame
     JFrame frame;
     etc. etc
}

Ответ 13

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

Ответ 14

Вы не должны расширять классы JFrame, JDialog, JPanel, JButton, Janything (хотя некоторые расширения для поведения таблиц доступны только в том случае, если вы его расширяете). Вы можете расширить JComponent, если вам нравится делать пользовательский компонент. Если предполагается реализовать модели (например, путем расширения абстрактных моделей), слушателей (например, путем расширения адаптеров), но это. Вам не нужно/нужно расширять компоненты swing обычно, и вам лучше не делать этого, так как это делает ваш код привязан к реализации суперкласса.

Ответ 15

Посмотрите API-интерфейс приложения (https://appframework.dev.java.net/ и http://java.sun.com/developer/technicalArticles/javase/swingappfr/. Это отличный API для создания вашего приложения swing, например: все стили (цвет, шрифт, значки...) определены в простом файле конфигурации.

Ответ 16

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

Поэтому, касательно ремонтопригодности и простоты модульного тестирования, я склоняюсь к идиоме "Presenter first" вместо Model View Controller (MVC) и других производных, которые инструктируют вас иметь представление о реальной логике приложения (модели). Лучшим ресурсом является веб-сайт группы, который представил его как мысль.

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