From: Roedy Green on
On Sun, 14 Feb 2010 20:38:29 -0800 (PST), Amr
<fromwindowstolinux(a)gmail.com> wrote, quoted or indirectly quoted
someone who said :

>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)
From: Daniel Pitts on
On 2/14/2010 8:38 PM, Amr wrote:
> 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.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Roedy Green on
On Mon, 15 Feb 2010 07:53:08 -0500, Joshua Cranmer
<Pidgeot18(a)verizon.invalid> wrote, quoted or indirectly quoted someone
who said :

>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)
From: RedGrittyBrick on
On 17/02/2010 07:33, Roedy Green wrote:
> On Mon, 15 Feb 2010 07:53:08 -0500, Joshua Cranmer
> <Pidgeot18(a)verizon.invalid> wrote, quoted or indirectly quoted someone
> who said :
>
>> 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?

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.

From: Lew on
Joshua Cranmer wrote, quoted or indirectly quoted someone who said :
>> 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.

Roedy Green wrote:
> 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.

--
Lew