Java – best practices for using JFrame constructors?

In my two Java classes and the books we use in them, the GUI using code involves a lot of JFrame constructors The standard technique in the book seems to be to initialize all components and add them to the JFrame in the constructor, and add anonymous event handlers to handle the required events, which is what my class advocates

This seems easy to understand and easy to use when creating a very simple GUI, but it quickly becomes ugly and cumbersome when making anything other than a very simple GUI This is a small code example I described:

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 use of constructors the best way to write swing applications in Java? If so, what techniques can I use to ensure that this type of constructor is organized and maintainable? If not, what is the recommended way to combine jframes in Java?

Solution

Unfortunately, there are many bad books there There are a lot of bad code

You should not abuse inheritance by using it where it is unnecessary (well, there's the double brace idiom, which is a complete inheritance abuse.) This applies to JFrame, JPanel, thread, and Java All contents except lang. object

In addition, it's a good idea to make fields private and may ultimately be the best It turns out that references to components usually don't need to be stored in fields, at least not