Should I subclass JFrame/JPanel or not?

Question

I was used to subclassing the window-classes in other programming environment, but in the java tutorials I usually see something like

JPanel p = new JPanel();
p.setLayout(new BoxLayout(p, BoxLayout.PAGE_AXIS));

p.add(aComponent);
p.add(anotherComponent);

So what are the conventions in Java regarding subclassing top-container classes?

Answer 1

Use the same principle as you would for all java classes. If you are modifying or extending the behaviour or functionality, then by all means, extend JPanel or JFrame. The trick is to think carefully and decide if you really are adding anything. In most cases when I see people extending JFrame it is unnecessary and wrong;

public class MyFrame extends JFrame {
  public static void main(String[] args) {
    new MyFrame().setVisible(true);
  }
}

Why bother extending JFrame? You haven't added anything! Composition is a much better option.

Extending JPanel is a little different. JPanel is a fairly abstract idea, its just a generic container for other components. IMHO it is valid to subclass JPanel to create a more concrete panel, and then use that in your application. It promotes OOP and encapsulation.

For example, say your GUI had 2 main display areas; one with some buttons/controls/inputs and another which displayed output (eg in a text area). It is perfectly acceptable to subclass JPanel to create a ControlPanel that contains the buttons/controls/inputs. This moves all the code into a nice neat module, cleaning up your class that contains and handles the main JFrame.

Answer 2

There is no rule for this, it depends how you think about your Object. You may have a JPanel which has a specific layout and bahavior, so its e.g. a VideoViewerPanel. But even this VideoViewerPanel may contain a JPanel which is only there to arrange some Buttons so you do not expicitly name it and just use it as JPanel.

Answer 3

I think this is related to the Liskov substitution principle, you should look into it.

Liskov substitution principle

Liskov substitution principle: Applied example

Answer 4

A well-known and good practice is to avoid subclassing top-level containers (JFrame, JDialog, JInternalFrame).

Regarding JPanel, several practices are in use:

• subclass it for every view (then add all components inside the subclass constructor)
• create a ViewBuilder (for each kind of view) that dynamically adds components to a "standard" JPanel

I generally use the first option, which seems more logical to me, but I also sometimes use the second way, with some level of adaptation: my view builder actually creates and stores (as fields) all components but adds them to an existing panel (passed as an argument).

For example, I use that in order to reuse sets of components: e.g. I have an AddressView class that works like that and I add it twice to a ContactView that subclasses JPanel, once for home address, once for office address.

One may say that I could also subclass JPanel for AddressView and then add 2 instances to my ContactView panel. The reason I don't do that is because Swing LayoutManagers don't support alignment of components across different panels, thus the resulting ContactView panel is not visually pleasing in this case.