2010-04-26 6 views
7

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

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

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); 
    } 

} 

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

ответ

1

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

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

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

+0

Итак, вы говорите, что не нужно излишне расширять JFrame, как я делал выше, но в отдельном классе создайте новый JFrame и добавьте в него компоненты? Это похоже на довольно разумный способ действий. Знаете ли вы о каких-либо хороших ссылках, чтобы узнать, как структурировать код swing gui? Спасибо за ввод. –

1

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

3

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

0

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

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