Визуальный редактор против ручного кода - PullRequest
2 голосов
/ 07 мая 2010

Я не уверен, как он использует другие фреймворки, но этот вопрос строго касается свинга Java.

Лучше ли использовать визуальный редактор для размещения объектов или для ручного кодирования размещения объектов на фрейме (менеджеры макетов или нулевые макеты)?

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

Просто интересно, что думают об этом люди?

Ответы [ 4 ]

5 голосов
/ 07 мая 2010

Я никогда не использую визуальный конструктор для своих интерфейсов Swing.

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

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

Два примера:

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

Еще один пункт: НИКОГДА использовать абсолютную позицию / размер в ваших интерфейсах, это ищет проблемы (ваш интерфейс может быть усечен на некоторых мониторах / системах ...)

2 голосов
/ 07 мая 2010

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

1 голос
/ 07 мая 2010

Лично я много лет использовал дизайнера GUI - в Eclipse, NetBeans, IntelliJ. И я никогда не был доволен теми ограничениями, которые они налагали, и кодом, который они создавали. В итоге у меня было так много пользовательских настроек, что использование дизайнеров мешало моей работе, а не помогало ей. И тогда я нашел MigLayout - для меня это программное обеспечение - Godsend. Ему удалось избавиться от ненужной сложности из моих лабораторий Swing и позволить мне создавать превосходные макеты с минимальными усилиями. Я не думаю, что MigLayout сложнее в использовании (как кто-то упоминал выше) - его, безусловно, сложнее использовать, чем CSS.

Даже если вам не нравится MigLayout, я советую держаться подальше от дизайнеров GUI. Более простой альтернативой MigLayout является JGoodies Forms Layout (который заменяет MiG), jide-oss также имеет несколько простых простых макетов. Однако, если вы хотите использовать конструктор, я бы посоветовал вам - IntelliJ IDEA Forms designer + JGoodies Forms - то есть, он генерирует гораздо больше поддерживаемого кода, чем NetBeans Matisse.

1 голос
/ 07 мая 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...