How do i know which superclass to inherit from...

[Amr]

public class Beeper extends JPanel implements ActionListener {}

that is a snippet from a code from an excercise give in the book "Sams
teach...."

my problem is, how do i know whether to give <extends JPanel> or
<extends JFrame>?
both extenstions are used in the book.

thank you very much for your help.

 

[Amr]

What do you want your class to do?  Which of JPanel or JFrame is most
like what you want your class to do?

The JPanel and JFrame classes are similar, but different in notable
ways, all of which are covered in the documentation.  It's hard to
understand why you'd be confused about which you want, if you know what
you want your own component to do.  And even if you're having trouble
figuring it out, you haven't told us what your component should do, so
we can't answer the question for you.

If you don't know what you want your own component to do, well…I could
see how that might be a problem.  But I don't think any of us can help
much with that.  

Pete

hi thank you for your reply.
the programme would have a button, and it would beep on each click.

anyway here is the full code

import java.awt.event.ActionListener;
import javax.swing.JFrame;

/**
*
* @author arshad
*/

import java.awt.*;
import java.awt.event.ActionEvent;
import javax.swing.*;
public class Beeper extends JPanel implements ActionListener {

JButton button;
public Beeper(){
super(new BorderLayout());
button=new JButton("Click Me");
button.setPreferredSize(new Dimension(200,80));
add(button,BorderLayout.CENTER);
button.addActionListener(this);

}

public void actionPerformed(ActionEvent e){
Toolkit.getDefaultToolkit().beep();
}
//
// create the Gui and show it. for thread safety,
// this method should be invoded from the evennt
dispatching thread

private static void createAndShowGUI(){
//create and set up the window.
JFrame frame =new JFrame("Beeper");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

//create and set up the content pane

JComponent newContentPane=new Beeper();
newContentPane.setOpaque(true); //content pane must be opaqu
frame.setContentPane(newContentPane);

//Display the window
frame.pack();
frame.setVisible(true);
}

public static void main(String arg[]){
//schedule a job for the even-dispatchin thread
//creating and shwoing this applications GUI

javax.swing.SwingUtilities.invokeLater(new Runnable(){ public
void run() { createAndShowGUI();}});
}
}

 

[markspace]

public class Beeper extends JPanel implements ActionListener {}

that is a snippet from a code from an excercise give in the book "Sams
teach...."

my problem is, how do i know whether to give <extends JPanel> or
<extends JFrame>?
both extenstions are used in the book.

thank you very much for your help.

Knowledge and experience. Knowledge of the API and what it does helps
you pick which classes are appropriate to inherit from. Experience
tells you which of those classes are the best, if any, for a given
circumstance. Unfortunately both knowledge and experience are hard to
get quickly. You'll have to learn at the best pace you can manage.

In my opinion, you usually should extend JPanel. JFrame is a top level
window, and that's pretty much all it can be. JPanel can fit in other
panels or in a JFrame. JPanel is more flexible, and easier for you to
use in a program.

Also, neither should extend ActionListener. Make that a separate class.
The behavior of being a JPanel (of JFrame) and the behavior of being
an ActionListener are fairly different. Don't make one object have both
behaviors, separate those two concepts so they're easier to deal with.

You often see simple teaching examples where one single class does
everything: it extends ActionListener, extends JFrame, and assembles
the entire GUI too. This isn't really appropriate for larger programs,
where this "do it all" behavior would make maintenance more difficult.
Separate those concerns to different classes. Those do it all classes
are really only trying to save space so the demo can be as brief as
possible.

I think those do it all classes are heading down the road of being a God
object, a known anti-pattern:

<http://en.wikipedia.org/wiki/God_object>

 

[RedGrittyBrick]

What do you want your class to do? Which of JPanel or JFrame is most
like what you want your class to do?

The JPanel and JFrame classes are similar, but different in notable
ways, all of which are covered in the documentation. It's hard to
understand why you'd be confused about which you want, if you know what
you want your own component to do. And even if you're having trouble
figuring it out, you haven't told us what your component should do, so
we can't answer the question for you.

If you don't know what you want your own component to do, well…I could
see how that might be a problem. But I don't think any of us can help
much with that.

Pete

hi thank you for your reply.
the programme would have a button, and it would beep on each click.

anyway here is the full code

import java.awt.event.ActionListener;
import javax.swing.JFrame;

/**
*
* @author arshad
*/

import java.awt.*;
import java.awt.event.ActionEvent;
import javax.swing.*;
public class Beeper extends JPanel implements ActionListener {

JButton button;
public Beeper(){
super(new BorderLayout());
button=new JButton("Click Me");
button.setPreferredSize(new Dimension(200,80));
add(button,BorderLayout.CENTER);
button.addActionListener(this);

}

public void actionPerformed(ActionEvent e){
Toolkit.getDefaultToolkit().beep();
}
//
// create the Gui and show it. for thread safety,
// this method should be invoded from the evennt
dispatching thread

private static void createAndShowGUI(){
//create and set up the window.
JFrame frame =new JFrame("Beeper");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

//create and set up the content pane

JComponent newContentPane=new Beeper();
newContentPane.setOpaque(true); //content pane must be opaqu
frame.setContentPane(newContentPane);

//Display the window
frame.pack();
frame.setVisible(true);
}

public static void main(String arg[]){
//schedule a job for the even-dispatchin thread
//creating and shwoing this applications GUI

javax.swing.SwingUtilities.invokeLater(new Runnable(){ public
void run() { createAndShowGUI();}});
}
}

In this example, the choice is purely arbitrary. You can write a program
with identical functionality where Beeper extends JFrame, JPanel or neither.

Many would argue that you should prefer composition over inheritance -
this would mean that class Beeper doesn't extend any other class, it
constructs a JFrame, JPanel and JButton in a method.

There are other aspects to this example which I dislike. If this is from
the book, I'd worry it is teaching bad habits.

 

[Joshua Cranmer]

my problem is, how do i know whether to give<extends JPanel> or
<extends JFrame>?
both extenstions are used in the book.

Traditionally, I make all of my custom panes extend JPanel; I can't
really think of a good case where JFrame needs to be extended: if I need
to make a powerful main window, I would likely just create a Main-ish
class that extends nothing and constructs the elaborate JFrame.

 

[Arne Vajhøj]

Traditionally, I make all of my custom panes extend JPanel; I can't
really think of a good case where JFrame needs to be extended: if I need
to make a powerful main window, I would likely just create a Main-ish
class that extends nothing and constructs the elaborate JFrame.

Extending JFrame is often seen - including in examples from SUN.

Arne

 

[Arne Vajhøj]

Also, neither should extend ActionListener. Make that a separate class.
The behavior of being a JPanel (of JFrame) and the behavior of being an
ActionListener are fairly different. Don't make one object have both
behaviors, separate those two concepts so they're easier to deal with.

You often see simple teaching examples where one single class does
everything: it extends ActionListener, extends JFrame, and assembles the
entire GUI too. This isn't really appropriate for larger programs, where
this "do it all" behavior would make maintenance more difficult.
Separate those concerns to different classes. Those do it all classes
are really only trying to save space so the demo can be as brief as
possible.

Good advice.

What is good for demo code is not necesarrily good for real world
programs.

Either a separate class or an anonymous class if the code is simple.

Arne

 

[Lew]

Extending JFrame is often seen - including in examples from SUN.

 

[Arne Vajhøj]

Yes.

Arne

 

[Roedy Green]

public class Beeper extends JPanel implements ActionListener {}

that is a snippet from a code from an excercise give in the book "Sams
teach...."

my problem is, how do i know whether to give <extends JPanel> or
<extends JFrame>?
both extenstions are used in the book.

thank you very much for your help.

You can extend only one class but implement several interfaces.

See http://mindprod.com/jgloss/extend.html
http://mindprod.com/jgloss/implements.html
http://mindprod.com/jgloss/interface.html
http://mindprod.com/jgloss/class.html

--
Roedy Green Canadian Mind Products
http://mindprod.com

Nothing has really happened until it has been recorded.
~ Virginia Woolf (born: 1882-01-25 died: 1941-03-28 at age: 59)

 

[Daniel Pitts]

public class Beeper extends JPanel implements ActionListener {}

that is a snippet from a code from an excercise give in the book "Sams
teach...."

my problem is, how do i know whether to give<extends JPanel> or
<extends JFrame>?
both extenstions are used in the book.

thank you very much for your help.

JFrame is for a full window, JPanel is a component within another window
or component.

It is my opinion that you should rarely extend *either* of these
classes. I have seen many examples which do extend from JFrame and
JPanel, but I personally avoid that practice. You should instead create
a JFrame object, and manipulate it through its public members.

 

[Roedy Green]

Traditionally, I make all of my custom panes extend JPanel; I can't
really think of a good case where JFrame needs to be extended: if I need
to make a powerful main window, I would likely just create a Main-ish
class that extends nothing and constructs the elaborate JFrame.

Can you please enumerate the reasons you would not extend a JFrame or
JPanel? It seems to me when you do, you nicely encapsulate, with
getters and private variables. What are the advantages of doing it the
other way?
--
Roedy Green Canadian Mind Products
http://mindprod.com

Nothing has really happened until it has been recorded.
~ Virginia Woolf (born: 1882-01-25 died: 1941-03-28 at age: 59)

 

[RedGrittyBrick]

Can you please enumerate the reasons you would not extend a JFrame or
JPanel? It seems to me when you do, you nicely encapsulate, with
getters and private variables. What are the advantages of doing it the
other way?

Effective Java, Joshua Bloch, Item 16
http://bit.ly/dcdcbc

Generally, from a business perspective at least, your application isn't
really a JFrame. A JFrame is something your application incidentally
has. Therefore it is no more appropriate for your app's main class to
extend JFrame than it is for it to extend (say) java.sql.connection.

 

[Lew]

Joshua Cranmer wrote, quoted or indirectly quoted someone who said :

Can you please enumerate the reasons you would not extend a JFrame or
JPanel? It seems to me when you do, you nicely encapsulate, with
getters and private variables. What are the advantages of doing it the
other way?

He already stated the main one: you don't need to extend JFrame. He obviously
analyzes his program as something that uses a JFrame, not /is-a/ JFrame.

Your question takes the opposite point of view from Joshua's statement. He
says,k "I can't really think of a good case where JFrame needs to be
extended." You ask for a good case where JFrame needs not to be extended. I
assert that burden of proof is on the case to extend.

Using a JFrame without extending it does not prevent you from having private
variables with accessor methods, nor from nicely encapsulating things.

It also locks you into using just the public interface of JFrame, insulating
you against possible changes in the API. This is good for the longevity of
your code.

There's little, if anything at all, you would want to do by extending a JFrame
that you cannot do by composing it. You would only extend JFrame to impose
custom public behaviors on the JFrame that it cannot already do itself.
Adding a JPanel is not a custom behavior, for example - JFrame already lets
you do that just fine.

As Joshua Bloch says in /Effective Java/
<http://java.sun.com/docs/books/effective/>
"Item 16: Favor composition over inheritance"
<http://books.google.com/books?id=ka2VUBqHiWkC&pg=PA81&lpg=PA81>

I hope Joshua will also explain his reasoning.

 

[Joshua Cranmer]

Can you please enumerate the reasons you would not extend a JFrame or
JPanel? It seems to me when you do, you nicely encapsulate, with
getters and private variables. What are the advantages of doing it the
other way?

Whenever I make a GUI, I've tended to think a lot more in terms of
bundles of components. In my most recent example, I essentially have a
StatisticsPane--a little window widget that contains displays of a set
of statistics. This is a pane, so it can be included somewhere in a
dialog, so it must be a JPanel (which is my reasoning for extending
JPanel: it's ultimately a JComponent, and JPanel is the most convenient
for me to extend).

Similarly, even the full, large window I have is merely a bundle of
components. Again, by that rationale, it can be contained in a
theoretically even larger program, so it shouldn't be a JFrame, it's a
JPanel. That's why I can't think of good times to extend JFrame: even
the large set of components is ultimately a bundle of components that
can be included elsewhere, perhaps having a related menu bar that may
need to be included as well.

I will admit that I probably am incorrectly extending JPanel to make all
of my panes (JComponent or even Container is probably better). I make my
panes components because I see them as atomic, indivisible visual areas
which are logically connected and can be independently used and
manipulated. I can use the StatisticsPane without having to use the
HistoryPane or ReviewPane, but I can't really use half of the ReviewPane
and still have a GUI that would make sense, for example.

 

[Roedy Green]

Can you please enumerate the reasons you would not extend a JFrame or
JPanel? It seems to me when you do, you nicely encapsulate, with
getters and private variables. What are the advantages of doing it the
other way?

I have collected your thoughts at
http://mindprod.com/jgloss/jframe.html#ISAVSHASA

If I missed something, please let me know.
--
Roedy Green Canadian Mind Products
http://mindprod.com

Nothing has really happened until it has been recorded.
~ Virginia Woolf (born: 1882-01-25 died: 1941-03-28 at age: 59)