Лучшая практика с конструкторами JFrame?

Question

Как в моих классах Java, так и в книгах, которые мы использовали в них, был представлен графический интерфейс с кодом, в котором активно участвовал конструктор JFrame. Стандартная техника в книгах, кажется, инициализирует все компоненты и добавляет их в JFrame в конструкторе, а также добавляет анонимные обработчики событий для обработки событий там, где это необходимо, и это то, что защищалось в моем классе.

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

public class FooFrame extends JFrame {

   JLabel inputLabel;
   JTextField inputField;
   JButton fooBtn;
   JPanel fooPanel;

   public FooFrame() {
      super("Foo");

      fooPanel = new JPanel();
      fooPanel.setLayout(new FlowLayout());


      inputLabel = new JLabel("Input stuff");
      fooPanel.add(inputLabel);

      inputField = new JTextField(20);
      fooPanel.add(inputField);

      fooBtn = new JButton("Do Foo");
      fooBtn.addActionListener(new ActionListener() {
         public void actionPerformed(ActionEvent e) {
            //handle event
         }
      });
      fooPanel.add(fooBtn);

      add(fooPanel, BorderLayout.CENTER);
   }

}

Является ли этот тип использования конструктора лучшим способом кодирования Swing-приложения в Java? Если да, какие методы я могу использовать, чтобы убедиться, что этот тип конструктора организован и поддерживается? Если нет, то каков рекомендуемый способ создания JFrame в Java?

Answer 1

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

Answer 2

К сожалению, есть много плохих книг. И много плохого кода.

Вы не должны злоупотреблять наследованием, используя его там, где это не нужно. (Хорошо, есть идиома Double Brace, которая является полным злоупотреблением наследованием.) Это относится к JFrame, JPanel, Thread и практически ко всему, кроме java.lang.Object.

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

Answer 3

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

Answer 4

У меня нет здесь определенных правил, кроме:

• всегда делайте атрибуты приватными, и когда это возможно, окончательные
• свести к минимуму использование приватных полей. Каждый компонент, который не используется вне конструктора, должен быть объявлен только в конструкторе, а не как поле (inputLabel в вашем примере)
• используйте анонимных слушателей только тогда, когда задействовано мало кода. Когда они становятся слишком большими, это обычно означает, что вы должны разбить их или объявить их закрытыми или отдельными классами
• И, как сказал Джонас, поддерживайте классы JFrame, JDialog и т. Д., Разбивая основные строительные блоки на отдельные классы.