This question already has answers here:
Why shouldn't you extend JFrame and other components? [duplicate]
(5 answers)
Closed 7 years ago.
I was used to do java swing programming with netbeans drag and drop, and never really cared too much about the code it generated. Now I am in the process of learning to code GUIs without drag and drops.
The fundamental problem occurred to me was, whether the window I am going to make IS_A JFrame or HAS_A JFrame. i.e whether to use inheritance or composition.
if MyWindow is a JFrame
public class MyWindow extends JFrame{
}
if MyWindow has a JFrame
public class MyWindow{
private JFrame frame;
}
Both seems fine to me. But I guess there should be a right way to do it out of these two. What is the correct way, and why?
If you want your class to behave as a window, then, you should extend it from JFrame (at least in my opinion). To my knowledge, this is how you should go about it.
If on the other hand, you want a class which has access to a window then you would go with the second option. That being said, you would still, at some point need to initialize a class which extends from JFrame.
EDIT: The answer to the question does say that, however it also says that it depends on what you are after. If I am understanding the answer correctly (maybe others could comment on this), if you have a scenario where you need a frame to print a list to a table, you could have a class which extends Frame and provides a utility method which takes in a list and prints it to a table. Your logic would then instantiate this class instead of the actual JFrame and use it to show the data.
My approach is that usually, I have a class which extends JFrame and provides a series of methods which make printing data easy. I would then have another class, which links logic and view layers. This class will have a reference to the JFrame extending class.
Related
This question already has answers here:
Java/Swing GUI best practices (from a code standpoint) [closed]
(2 answers)
Closed 4 years ago.
So what's the best practice, use a JFrame as the one that contains the main method, or just create a main class, and call the JFrame?
I'm not sure it matters at all, but i'm wondering if there are any advantages using the main in JFrame class or not?
I personally try to keep the main method in its own class because maybe you want to do more than just start the JFrame at startup.
But that really depends on what you want to do, if you only want to start the JFrame then the main method in the JFrame is also good.
You may also want to have a look at this post
This question already has an answer here:
Dispose JFrame from another class
(1 answer)
Closed 7 years ago.
I have a quick question regarding JFrames and disposing them properly. I have a game that has multiple levels, I wish to dispose of the frame in use when another is created with a new level.
The program I am currently working on extends a JFrame which has always confused me as I don't know what that JFrame is called.
Anyway, I have another class that extends a JPanel. In this class I have a method that, when the game state is completed, removes all instances and closes the JFrame. Yet this does not work because I cannot get the frame of the frame, instead I get multiple instances of the same JFrame.
So my set up looks like this:
Class 1 extends JFrame
....
....
....
Class 2 extends JPanel
...
...
method(clears everything + gets new JFrame for new level)
...
Sorry if that is vague, I don't want to post hundreds of lines of code for a short question. I know others have asked this question but I can never seem to get it to work for me.
So once again, my question is simply how do you close a JFrame in another class method.
(Please note everything works perfectly, I just can't close the frame without it breaking completely on me)
dispose() is an insance-level method. If you have object o, which is of JFrame or an inherited class, then o.dispose() should dispose it. If you are not sure that o is initialized when you want to dispose it, then
if (o != null) {
o.dispose();
}
If you simply call dispose() from somewhere, you will get an exception if that object/class does not have a dispose object. So, if you want to dispose o from class A, then you should call o.dispose() in one of the methods, but make sure that you initialize o correctly before that.
First of all, I would like you to know that I'm new in Java world; so please forgive me if my question is basic.
I'm working with a team, and we are trying to create a browser using Java.
To begin with, we are watching some tutorials, and all of them begin with a class that extends JFrame. What does this JFrame do?
This could easily be answered in a 10 second Google search... But to answer your question anyway, a JFrame is an extension of java.awt.Frame, which displays a graphical window to the user, in which you can house components and graphics on.
These components range from JButton's JLabel's all the way to Menu bars, etc.
Also, extending a JFrame is never a good idea. It works fine, but for the best code readability, and usage, do not do it. There are plenty of reasons why, and they are explained thoroughly here:
Why shouldn't you extend JFrame and other components?
Extract:
Generally speaking, extending the component tends to be done strictly to use the component. This severely limits your options in unnecessary ways in terms of design, so that your classes can't extend different classes, you can't hide the JFrame's methods causing it to be more difficult to maintain and easier to trigger unexpected bugs when using the class.
More can be found below in the links provided:
JavaDoc for JFrame
How to use a JFrame
I'm fairly new to programming and definitely new to Java. I'm teaching myself before I begin courses this fall in computer science and I have a curiosity about syntax that I have seen from two different authors.
In one book, a JFrame is usually established by making the class an extension of JFrame
public class MyClass extends JFrame {
etc
However, another author, and also questions on this site usually establish a frame inside of the class as such:
public class MyClass {
JFrame frame = new JFrame();
Firstly, what are the advantages of one over the other?
It seems to me, and I'm hardly an expert, that making a class an extension of JFrame would make it easier to set parameters of the frame and also to add components to it.
IE in the extension format, you simply say
add(component);
However, in the other format, on must type:
frame.getContentPane().add(component);
which seems more tedious.
Can someone please explain succinctly the reason behind this or if it is simply a matter of preference. I have looked into this and have been unable to get a straight forward answer.
There are philosophical and practical reasons many (including I) prefer the latter:
Prefer composition over inheritance in general.
Only extend a class if you plan to alter its innate behavior (i.e., override one or more of its methods).
By not extending JFrame, it is easier to create classes that maximize cohesion and minimize coupling, and to write clean MVC-based code. A more important example of this concept is to avoid having your GUI code (your view code) implement any listener interfaces (your control code). It's OK for baby programs, but not for grown-up code that has the potential of getting complex.
By not extending a large and complex class such as JFrame, you reduce the risk of difficult to debug hidden override malbehaviors. Try extending JFrame or JPanel and giving the class a getX() and getY() method to see what I mean!
If you're using an IDE that gives suggestions of methods available to objects of your class, you greatly reduce the number (and complexity) of possible suggested methods if you don't override a huge complex class such as JFrame.
By gearing your Swing GUI's to create JPanels rather than override JFrame, you greatly increase the flexibility of how that GUI can be used. Now it can be placed in a JDialog, JOptionPane, a JApplet, inside of another JPanel as part of a more complex GUI or as part of a CardLayout view swap.... and I can go on and on.
On the same token as above, many of my GUI's do just that, create JPanels, that I can test in isolation by putting them in JFrames in small test programs before adding them to the greater whole of the application.
Traditionally you're not creating a special type of frame, so you shouldn't extend JFrame.
You're creating a JFrame and putting content in it, so the latter method is preferrable.
I.e. it's from an object oriented point of view it's cleaner to USE a JFrame, instead of extending one.
I did a GUI by my own which extends a JFrame. And I saw a program code from advanced programmer who imports the JFrame. I might know the difference between import and extend. But what advantage is given by which sort of implementation?
By "import" i presume you mean that your programmer friend's class uses a JFrame whereas your class is a JFrame. I don't think extending a JFrame is "wrong", but my preferred approach is to create and configure a JFrame rather than extending it. If there's really some protected method that you need access to then you might extend it but i'm sure that, in most cases, simply creating and configuring a standard JFrame is right - i have never found a need to extend it.
In other words, by inheriting JFrame with no real need to do that, you're just complicating your system. This is a same argument you would have when choosing inheritance versus aggregation with any other class. To find out what's right, you need to ask yourself if the class you're writing really is a JFrame which is a window widget. I suspect that in most cases you are writing a Swing application which needs a JFrame but which isn't one itself - it's a Swing application with some other purpose.