GroupLayout: стоит ли учиться?

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

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

GroupLayout на самом деле не предназначен для -кодирование; это намного, намного более многословно, чем любой другой менеджер компоновки (за исключением, возможно, GridBagLayout). Поскольку вы говорите, что вы новичок в Swing, я предлагаю начать с основных менеджеров компоновки (BorderLayout и FlowLayout); вы можете использовать их в NetBeans, щелкнув панель или рамку правой кнопкой мыши и выбрав «Установить макет». После того, как вы ознакомитесь с ними, я предлагаю вам проверить MiGLayout.

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

GroupLayout стоит научиться использовать программно.

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

groupLayout.setAutoCreateGaps(true);
groupLayout.setAutoCreateContainerGaps(true);

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

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

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

Мой совет после многих лет создания графического интерфейса Java и его поддержки состоит в том, чтобы изучить и использовать самый мощный менеджер компоновки, который вы можете освоить за два часа и который вы никогда не забудете, а затем компоновать свой графический интерфейс с помощью вложенных контейнеров, используя этот менеджер компоновки и основные BorderLayout/GridLayout/FlowLayout/BoxLayout.

Если вы склонны к стилю программы VB, вы тратите время на GroupLayouts. В противном случае попробуйте разобраться с GridBagLayout Manager на подходящих примерах. Это лучше всего подходит для тех, кто хочет, чтобы каждый компонент графического интерфейса находился под нашим контролем пера (мы должны писать, а не IDE). Хороший разработчик Java должен проводить время с объектами графического интерфейса и бизнес-объектами и должен знать, как их разделить. Л. Санкаранараянан.