Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Extends JFrame vs. creating it inside the program

When making an application using Swing, I've seen people do one of the two things to create a JFrame. Which is a better approach and why?

I'm a beginner at Java and programming. My only source of learning is books, YouTube and Stack Overflow.

import {imports};

public class GuiApp1 {

    public static void main(String[] args) {

        new GuiApp1();
    }

    public GuiApp1()  {
        JFrame guiFrame = new JFrame();

        guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        guiFrame.setTitle("Example GUI");
        guiFrame.setSize(300,250);
        ................
    }

AND

import {imports};

public class GuiApp1 extends JFrame {

    public Execute() {
        getContentPane().setBackground(Color.WHITE);
        getContentPane().setLayout(null);
        setSize(800, 600);
        .............
    }

    public static void main(String[] args) {
        Execute frame1 = new Execute();
        frame1.setVisible(true);

    }
}
like image 229
satnam Avatar asked Feb 25 '14 03:02

satnam


People also ask

Should you extend JFrame?

Thoughts: Avoid extending JFrame as it ties your GUI to being, well a JFrame. If instead you concentrate on creating JPanels instead, then you have the freedom to use these JPanels anywhere needed -- in a JFrame, or JDialog, or JApplet, or inside of another JPanel, or swapped with other JPanels via a CardLayout.

What does extends JFrame do in Java?

The Java system displays a frame on the screen when needed (you saw them at work in the previous program). The class myFrame extends the class JFrame . The paint() method of a JFrame object is called by the Java system (not by you) to finish the display.

What is difference between JFrame and Swing?

A JFrame is a Swing component which is the newer one, well today's java GUI development uses mostly Swing as an advantage you can have a lot of community support on it. as far as I know Swing has LookAndFeel Feature that you can configure to change the look of your GUI with just few line of codes.


5 Answers

Thoughts:

  • Avoid extending JFrame as it ties your GUI to being, well a JFrame. If instead you concentrate on creating JPanels instead, then you have the freedom to use these JPanels anywhere needed -- in a JFrame, or JDialog, or JApplet, or inside of another JPanel, or swapped with other JPanels via a CardLayout.
  • Avoid inheritance in general, especially of complex classes. This will prevent pernicious errors, such as inadvertent method overrides (try creating a JFrame or JPanel that has a getX() and getY() method to see what I mean!).
  • Avoid inheritance of complex classes if you are using an IDE: If you override a complex class, when you call methods on objects of these classes, you will have many, too many, choices of methods offered to you.
  • Encapsulation is good, is and allows for creation of safer code. Expose only that which needs to be exposed, and control that exposure as much as possible.
like image 138
Hovercraft Full Of Eels Avatar answered Oct 03 '22 10:10

Hovercraft Full Of Eels


Prefer composition over inheritance.

The 2nd example uses inheritance, but for no good reason, since it does not change the functionality of JFrame.


As an aside, if those are examples of code you are seeing, find a new source1 supplementary. Even in the few code lines shown, each does highly questionable things. E.G.

  1. Neither GUI is created on the Event Dispatch Thread.
  2. getContentPane().setBackground(Color.WHITE); getContentPane().setLayout(null); setSize(800, 600);
    • The first part of the 1st line (getContentPane()) has not been necessary since Java 1.5
    • The second line uses a null layout, which will break in more ways I can count or describe.
    • The third line should best be replaced with pack();
  3. JFrame guiFrame = new JFrame(); guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); guiFrame.setTitle("Example GUI"); guiFrame.setSize(300,250);
    • The first and 3rd lines could be contracted to:
      JFrame guiFrame = new JFrame("Example GUI");
    • The 2nd line is better set to guiFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
    • The 3rd line again sets a size to the frame.

Supplement

  1. Having mentioned you do search SO, here is a tip. Check out the posts of the top 15 providers of answers in the Swing top users. Whatever advice/code you glean from these people, would commit few if any of the mistakes in those code samples.

    Some don't often (or ever) provide self contained examples like a few of us commonly do (and don't look to those examples necessarily for OO design as opposed to just technique), but whatever code they provide, or advice they give, should be highly considered.
like image 33
Andrew Thompson Avatar answered Oct 03 '22 10:10

Andrew Thompson


Personally, the first approach (creating an instance of JFrame) is preferred, I prefer this because...

It doesn't lock your application into a dedicated container...you see a lot of people wanting to add applets to frames and frames to applets, if they had simple put the majority of there GUI in a JPanel to start with, they wouldn't have these issues.

It also means that the UI you create is much more flexible. For example, you can re-use it, either in the current application or future applications, you don't lock yourself in.

The main gripe I have with extending JFrame is, you're not actually adding any new features or functionality to it, which could be effectively re-used beyond using setVisible

The other issue I have with extending JFrame is people then promptly override paint, which is really, really bad. There are so many issues with doing this it's simply painful to have to repeatedly list them...

So...for more 2 cents worth. Create an instance of JFrame and add your content to it. If required, create a static method call showMyAwesomeGUI which does it for you...

like image 23
MadProgrammer Avatar answered Oct 03 '22 10:10

MadProgrammer


The first approach is better.

Typically you are not adding any new functionality to the frame so creating a direct instance of the class makes sense.

like image 20
Reimeus Avatar answered Oct 03 '22 08:10

Reimeus


Go for the first approach.

Because with that you can have more frames to be created. Because the application can have more than one window. As in the second case you can't create more frames.

like image 34
ravi.patel Avatar answered Oct 03 '22 09:10

ravi.patel