extending JFrame vs having JFrame as a field

[Christoph Czon]

What is good class design for creating a GUI? I want to setup a JFrame in which I put a JPanel and add all the contents into the JPanel.

I saw sample code where they extend the JFrame class and do all the work inside this subclass. However my idea was to write an entirely new class which contains a JFrame merely as a field, add some private methods for adding all the contents and then return the complete JFrame. The difference is that the second approach doesn't extend JFrame. What they both have in common is that I have a method (or a constructor in the first case) that returns my finished JFrame.

Since I don't really want to modify the behaviour of JFrame, I don't see any reason to extend it. Which way is better or more commonly used?
I will post an example for each approach:

1) extending JFrame:

class GUI extends JFrame {
    GUI() {
        JPanel content = new JPanel();
        //fill the JPanel with all the lower panels and their respective contents.
    }
}

2) creating an entirely new class not related to JFrame:

class GUI{
    private JFrame outerFrame;
    private JPanel content;
    .... //all the necessary Components
    public JFrame getFinishedOuterFrame(){
        //fill the panel with the components and then add it to the JFrame
        return outerFrame;
    }
}

The invoking method would then simply setVisibility(true) and the JFrame is ready for use.

[Campbell Ritchie]

If you are not modifying JFrame, it is probably better to have it as a field rather than extending it.

[Bernhard Haeussermann]

Hello Christoph,

To my opinion it doesn't really matter if you extend JFrame or have it as a field. In both versions of the GUI class you can do things like defining ActionListener's as inner classes and providing public methods for doing something to the JFrame or a component inside of it.
One thing that you cannot do in the second version of the GUI class, as you've noted, is to alter the behaviour of the JFrame object (strictly speaking it is possible here too, but it's a bit more complicated and might make your code a bit messy). By extending JFrame, you keep this possibility open, in case the need may arise in the future.
The only drawback that I note with the extending option is that it disables you to make GUI extend any other class (which would be unlikely to be a good idea anyway).
Although I do appreciate the fact that you critically question whether the method used in the text book is the best way to do it ( ), I would personally prefer the extending option. After all, the inheritance makes sense intuitively: the GUI "is a" JFrame, right?

[pete stein]

I disagree. You should only extend when you need to extend, else you risk problems. For instance, have you ever created a GUI that extends JFrame give the class x and y int variables and then give it an int getX() and int getY() method? Try this and you'll see what I mean about unwanted side effects that can occur when classes are extended that don't need to be extended. Issue number two: have you ever created a GUI as a JFrame and then later decide that it should be part of a larger more complex GUI and displayed as a JDialog? Or as a JPanel in part of a larger GUI? Extending it as a JFrame constrains your code unnecessarily preventing this flexibility.

Any debate is most welcome.

[Bernhard Haeussermann]

I think there are pro's and cons. In the second version of the GUI class, as I've mentioned before, one can include methods for the client that manipulate the JFrame. The problem here is that the client will have to call methods on the JFrame object to do some things and methods on the GUI object to do some other things.

Of course, when extending JFrame, one needs to be careful of accidentally overriding methods of JFrame. I cannot recall, however, that something like that has ever happened to me. If you use good descriptive names for your methods, this is unlikely to happen.

As for the issue of needing to change the JFrame into a JDialog or JPanel - would this change necessarily be more work when GUI extends JFrame? When I think about it, I'm not quite sure. I would need to try actually doing it for both versions of the GUI class.

I'm still not convinced that having JFrame as a field is the better way to go. I suggest that you consider these comments and decide for yourself.

[Bernhard Haeussermann]

Maybe it would be better to make GUI extend JPanel from the start. That way the client can decide if he would like to wrap it directly into a JFrame or put it into a JFrame along with other JPanel's, or put it into a JDialog.

[pete stein]

Bernhard Haeussermann wrote:
I think there are pro's and cons. In the second version of the GUI class, as I've mentioned before, one can include methods for the client that manipulate the JFrame. The problem here is that the client will have to call methods on the JFrame object to do some things and methods on the GUI object to do some other things.

And it is almost always safer to make public method calls on an object rather than muck with an object's internals.

Of course, when extending JFrame, one needs to be careful of accidentally overriding methods of JFrame. I cannot recall, however, that something like that has ever happened to me. If you use good descriptive names for your methods, this is unlikely to happen.

I wish I could say the same and am impressed. I find that the larger and more complex the project, the greater the chance that this sort of thing happens to me. And so while the risk of seeing unwanted side effects from unnecessarily extending a class is low for small demo programs, and some may argue, why worry about it for larger projects, but for me I feel that it's a good idea to keep using good habits with small programs so I will automatically do them with big projects.

As for the issue of needing to change the JFrame into a JDialog or JPanel - would this change necessarily be more work when GUI extends JFrame? When I think about it, I'm not quite sure. I would need to try actually doing it for both versions of the GUI class.

Hang around this forum and you'll see many questions deriving from just this problem.

[Christoph Czon]

Hmm ok, I think I'll be going with the non-extending version then because there doesn't seem to be a special reason for extending JFrame. Also like this I save the possibility to extend the class when it's really needed. Thanks for discussing!

Maybe you can also give me hints on a general problem I always face in connection with Swing / GUIs:

I have a working program which runs fine via terminal. I enter all input into a textfile beforehand and then I read the file with java.util.Scanner. Eventually I find out it would be nice to transform the program into a GUI to make it more user friendly or generally speaking more "modern". At this point unfortunately I always get stuck because I don't know how to start. There's so many ways to put Contents into Containers (i.e: general design issues like my initial question. My next question would have been where to put the elements of the container: create an own class for each button I want to add or create a class which contains a panel and then add the buttons into the panel from inside that class and so on...) that I always get overwhelmed by the possibilities because I lack experience with Swing.

Usually I end up creating only one class and writing tons of static methods which I simply call from main(). I can tell myself that this can't be good design. However I don't really know how to do it more elegantly. Can you give me some advice on how to make a good start? I also read most of the tutorials on the official java website. However those only explain how to work with the various elements but that is already one step ahead. I hope you get the idea at what stage I am. I understand most of the Swing structures already (on a basic level) but I haven't found the big picture behind it yet.