Руководящие принципы GUI для качелей

Есть ли ресурс, в котором объясняется дизайн GUI для swing? Как и лучшие практики и т.д.

Ответ 1

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

  • Никогда не используйте GridBagLayout. Захватите TableLayout. Это радикально упрощает макет для вас Swing UI. GridBagLayout - дьявол.
  • Не перестраивайте компоненты только для правильной компоновки (т.е. встроенного BoxLayout и т.д.). См. Пункт 1, как это сделать. На экране есть проблемы с производительностью, имеющие компоненты на экране.
  • Отделите свою программу вдоль линий MVC. Swing имеет разделение вида и модели, но в больших программах представление (то есть какие подклассы Swing Component) превращается в просмотр/контроллер psuedo, только усложняя процесс повторного использования и обслуживания. Он быстро превращается в спагетти. Разбейте привычку и создайте класс контроллера, который НЕ расширяет Swing. То же самое касается модели (без качания). Контроллер создает экземпляры классов высокого уровня и прокладывает себя как слушатель к представлениям.
  • Упростить всплывающие диалоговые окна, используя только простые панели. Не подклассы JDialog. Создайте класс диалогового окна многократного использования, который обертывает панель, которая может использоваться как JOptionPane. Ваши панели не будут привязаны только к диалогам и могут быть повторно использованы. Это очень легко, когда вы работаете таким образом.
  • Избегайте actionlistener/command. Это старый мусор и не очень многоразовый. Используйте AbstractAction (классы anon - ваш выбор. У меня нет проблем с ними). AbstractAction инкапсулирует текст, иконку, пневмонику, ускорители, многократно используемые в кнопках, всплывающие окна, меню, ручки, включающие включенные/отключенные состояния, могут совместно использоваться несколькими компонентами, а также является основой для InputMap/ActionMaps для сопоставления штрихов клавиатуры с действиями. ActionMaps дает вам массу возможностей для повторного использования.
  • Лучше всего просматривать события отправки контроллеру. Я не говорю о мусоре мыши/клавиатуры, но о событиях высокого уровня. Подобно NewUserEvent, AddUserEvent, DeleteUserEvent и т.д. Контролируйте ваш контроллер этими бизнес-событиями высокого уровня. Это будет способствовать инкапсуляции, сохраняя проблемы представления (следует ли использовать таблицу, список, дерево или что-то еще?), Отделенные от потока приложения. Контроллеру не важно, щелкнул ли пользователь кнопку, меню или флажок.
  • События предназначены не только для контроллера. Swing - это программирование событий. Ваша модель будет делать вещи с SwingThread или в фоновом режиме. Отправка событий обратно на контроллер - это очень простой способ реагировать на происходящее на уровне модели, который может использовать потоки для работы.
  • Понять правила качания нитей! Вы будете удивлены, как мало кто понимает, что Swing является однопоточным, и что это означает для многопоточных приложений.
  • Поймите, что делает SwingUtilities.invokeLater().
  • Никогда не используйте SwingUtilities.invokeAndWait(). Ты делаешь это неправильно. Не пытайтесь писать синхронный код при программировании событий. (* Есть некоторые угловые случаи, когда invokeAndWait() допустим, но в 99% случаев вам не требуется invokeAndWait()).
  • Если вы начинаете новый проект с нуля, пропустите Swing. Это старое, и все. Sun никогда не заботился о клиенте, как о сервере. Свинг был сохранен плохо, и с момента его написания не было достигнуто большого прогресса. JavaFX еще не существует и страдает от множества грехов Swing. Я бы сказал, посмотрите Apache Pivot. Много новых идей и лучшего дизайна и активного сообщества.

Ответ 2

Я написал список рекомендаций здесь.

Ответ 3

В более крупных проектах качания я занимаюсь таким приложением:

  • У вас есть один класс для каждого элемента GUI, например JPanel, JDialog и т.д.

  • Используйте отдельный пакет для каждого экрана, особенно если вам нужно реализовать настраиваемые TableModels или другие сложные структуры данных.

  • Не используйте анонимные и внутренние классы, реализуйте вместо этого ActionListener и проверяйте там ActionEvent.getActionCommand().

EDIT: если вы ищете учебник или введение, вы можете начать здесь

Ответ 5

Вы можете проверить идеи, лежащие в основе FEST - рамки тестирования swing. На главном сайте здесь, и проект размещен здесь

Ответ 7

У меня также есть некоторые рекомендации:

1) Используйте Maven и разделите свое приложение на модули (просмотр, контроллер, сервис, настойчивость, утилиты, модель). Убедитесь, что вы поместите свои компоненты Swing и зависимости только в виде пакета, поэтому, если вы хотите изменить структуру представления в какой-то день, вы можете просто переопределить модуль просмотра, но вы можете оставить свою бизнес-логику, контроллеры и т.д. Неповрежденными.

2) Используйте GridBagLayout, потому что его очень гибкий и настраиваемый

3) Используйте SwingTemplate (я могу дать вам пример, если вы хотите)

4) Создайте SwingFactory, который создает компоненты, чтобы вы могли уменьшить количество строк кода, поскольку JFrames oro намереваются быть очень большими классами...

5) Пусть представление (JFrame, JDialog и т.д.) зависит от контроллеров. Выполняйте только ввод валидации на JFrames, а затем передавайте параметры контроллерам. Они решат, какая бизнес-логика (служба, процессоры и т.д.) Будет запущена.

6) Используйте много перечислений

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

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

9) Протестируйте свое приложение: сделайте выбор между: TDD (Test Driven Design) или DDT (Design Driven Testing)

10) Никогда не ставьте какую-либо бизнес-логику на JFrames, потому что она уродлива и не очень похожа на модель-View-Controller. JFrames не интересуются тем, как данные были обработаны.

Надеюсь, что это поможет.