Best Practice With JFrame Constructors?

In both my Java classes, and the books we used in them laying out a GUI with code heavily involved the constructor of the JFrame. The standard technique in the books seems to be to initialize all components and add them to the JFrame in the const开发者_如何学编程ructor, and add anonymous event handlers to handle events where needed, and this is what has been advocated in my class.

This seems to be pretty easy to understand, and easy to work with when creating a very simple GUI, but seems to quickly get ugly and cumbersome when making anything other than a very simple gui. Here is a small code sample of what I'm describing:

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

}

Is this type of use of the constructor the best way to code a Swing application in java? If so, what techniques can I use to make sure this type of constructor is organized and maintainable? If not, what is the recommended way to approach putting together a JFrame in java?

When you get a more complex UI I recommend that you separate different JPanels from the JFrame, so they become "modules" or "building blocks" of your user interface.

Unfortunately there are a lot of bad books out there. And a lot of bad code.

You should not abuse inheritance by using it where not necessary. (Okay, there is the Double Brace idiom, which is complete inheritance abuse.) This applies to JFrame, JPanel, Thread and practically everything except java.lang.Object.

Also it is an extremely good idea to make fields private and where possible final. It turns out that references to components generally don't need to be stored in fields, at least not like this.

As you just said, this seems to be a technique which is taught by the books. What I used to do, to at least have a bit of an overview about the different aspects is to separate the ui-views from ui-controllers. In your case this would mean, that you could write separated classes for Event Handling. Another helpful technique is to use private methods to separate different parts of your UI. In other words, the general Refactoring techniques might be helpful in this case as well.

I have no definite rules here, except :

• always make attributes private, and when it's possible final
• minimize the use of private fields. Every component that is not used outside the constructor should only be declared in the constructor and not as a field (inputLabel in your example)
• only use anonymous listeners when there's little code involved. When they grow too big, it usually means you have to break them up or declare them in private, or separate classes
• And like Jonas said keep the JFrame, JDialog etc. classes lean by breaking the main building blocks in separate classes.