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.
Related
I read that the window that appears using the JFrame class is a Container with the predefined features (minimize, closing), but I found people who were not using the JFrame class but other classes (one of them the Container) which was far more hard.
Why do they do it that way? Is it because the JFrame class always has a predefined window that you can manipulate some aspects of it but the Container and the other classes give you more freedom of how you can create a window?
For an example to my question (I don't know if its real or not) in the JFrame class the close button always go to right to corner of the window but if I do it the other way you can put it everywhere you like. (If it can be answered with a yes or no).
So my qusetion is why they do it that way
There are two "main" reasons why. First is about overall good programming.
We tend to recommend avoiding extending from classes to which we are not adding any new functionality or repeatable features. If the whole reason for extending from JFrame is just so you can display some components, then it's really not a good choice or starting point.
JFrame is also a complex, compound component. That is, it's actually made up of a number of other layered components which work together to provide an overall experience.
*From How to Use Root Panes
This means that there is a lot of added complexity you'd have to be willing to manage if you extended from this class, a lot of overhead just to display a few components.
In principle, it's better to use composition over inheritance, which leads into the second point.
Extending from any class locks you into that classes use case. In the case of JFrame, you can only ever display what ever is managed by the class via a JFrame, there is no flexibility or entry point for re-usablility.
If, instead, you started with a base class of, say JPanel, you can add that to what ever container you want when ever you want, it increases the flexibility and re-usability of the class over all.
For an exaple to my question(i dont know if its real or not) in the JFrame class the close button always go to right to corner of the window but if i do it the other way you can put it everywhere you like.(If it can be answered with a yes or no)
Yes and no. The frame border is defined by the look and feel delegate, so you're not actually starting at the right place to begin with anyway.
Most look and feel delegates delegate the frame border to the native platform, in the case of Windows, yes, the close button is on the right, on Mac it's on the left.
In any case, it's better to support user expectations, placing the close button in an unusual place might make the UI "pretty", but diminishes the user experience - as a general guide line, don't diminish the user experience, no matter how awesome your program or UI, user's won't like you for it - but that is a (very broad) question for another day
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
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.
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'm looking for a specific functionality. I want to load a class that extends JPanel for instance and show that JPanel on a separate GUI class.
I'm looking for the ability to switch several of these classes out at will. I have an idea for an educational game software and the classes would be the different games.
I do realize that I can instantiate an instance of each class in my GUI class, but I ran into the issue of them not displaying properly when I try to switch between them. repaint() only works on the last class I added to my content pane. Not sure why as the multiple classes I instantiate are present, it just seems to ignore the preceding classes.
How to swap components?
You can either use CardLayout to switch all the component or add/remove them calling
container.revalidate();
container.repaint();