Расширяет JFrame против создания его внутри программы

При создании приложения с использованием Swing я видел, как люди делали одну из двух вещей для создания JFrame. Какой подход лучше и почему?

Я новичок в Java и программировании. Мой единственный источник обучения - книги, YouTube и Stack Overflow.

import {imports};

public class GuiApp1 {

    public static void main(String[] args) {

        new GuiApp1();
    }

    public GuiApp1()  {
        JFrame guiFrame = new JFrame();

        guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        guiFrame.setTitle("Example GUI");
        guiFrame.setSize(300,250);
        ................
    }

А ТАКЖЕ

import {imports};

public class GuiApp1 extends JFrame {

    public Execute() {
        getContentPane().setBackground(Color.WHITE);
        getContentPane().setLayout(null);
        setSize(800, 600);
        .............
    }

    public static void main(String[] args) {
        Execute frame1 = new Execute();
        frame1.setVisible(true);

    }
}

6 ответов

Решение

Мысли:

  • Избегайте расширения JFrame, так как он связывает ваш графический интерфейс с JFrame. Если вместо этого вы сконцентрируетесь на создании JPanels, то у вас есть свобода использовать эти JPanels везде, где это необходимо - в JFrame, или JDialog, или JApplet, или внутри другого JPanel, или обменяться с другими JPanels через CardLayout.
  • Избегайте наследования вообще, особенно сложных классов. Это предотвратит пагубные ошибки, например непреднамеренные переопределения методов (попробуйте создать JFrame или JPanel с getX() а также getY() способ понять, что я имею в виду!).
  • Избегайте наследования сложных классов, если вы используете IDE: если вы переопределяете сложный класс, когда вы вызываете методы для объектов этих классов, у вас будет много, слишком много вариантов методов, предлагаемых вам.
  • Инкапсуляция хороша, позволяет создавать более безопасный код. Выставляйте только то, что нужно подвергать воздействию, и максимально контролируйте это воздействие.

Предпочитаю композицию наследованию.

Во втором примере используется наследование, но без веской причины, поскольку оно не меняет функциональность JFrame,


Кроме того, если это примеры кода, который вы видите, найдите новый дополнительный источник 1. Даже в нескольких показанных строках кода каждая делает очень сомнительные вещи. НАПРИМЕР

  1. Ни один GUI не создается в потоке диспетчеризации событий.
  2. getContentPane().setBackground(Color.WHITE); getContentPane().setLayout(null); setSize(800, 600);
    • Первая часть 1-й строки (getContentPane()) не было необходимости с Java 1.5
    • Вторая строка использует null макет, который сломается больше способов, которые я могу сосчитать или описать.
    • Третью строку лучше всего заменить на pack();
  3. JFrame guiFrame = new JFrame(); guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); guiFrame.setTitle("Example GUI"); guiFrame.setSize(300,250);
    • Первая и третья строки могут быть сокращены до:
      JFrame guiFrame = new JFrame("Example GUI");
    • 2-я строка лучше установлена guiFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
    • 3-я строка снова устанавливает размер кадра.

дополнение

  1. Упомянув, что вы делаете поиск ТАК, вот совет. Проверьте сообщения 15 лучших поставщиков ответов в топ пользователей Swing. Какой бы совет / код вы ни почерпнули у этих людей, вы совершите несколько ошибок в этих примерах кода.

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

Лично первый подход (создание экземпляра JFrame) является предпочтительным, я предпочитаю это, потому что...

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

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

Основная схватка у меня с удлинением JFrame вы фактически не добавляете к нему никаких новых функций или функций, которые могут быть эффективно использованы повторно после использования setVisible

Другая проблема, которую я имею с расширением JFrame люди тогда быстро отменяют paint, что действительно, очень плохо. Есть так много проблем с этим, просто больно многократно перечислять их...

Итак... для более 2 центов стоит. Создать экземпляр JFrame и добавьте свой контент к нему. При необходимости создайте static вызов метода showMyAwesomeGUI который делает это для вас...

Первый подход лучше.

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

Перейти на первый подход.

Потому что с этим вы можете иметь больше кадров, которые будут созданы. Потому что приложение может иметь более одного окна. Как и во втором случае, вы не можете создавать больше кадров.

Это не имеет значения.

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

Теперь, если вы пишете что-то, что может работать из командной строки или может быть программой с графическим интерфейсом, очевидно, вы могли бы хотеть "основной" класс, который не был классом с графическим интерфейсом.

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

Другие вопросы по тегам