GUI Classes -- How Big? A Question of Style...

[Hal Vaughan]

I think a lot of this is definately a question of personal programming
style, but I'm new to Java and would like to hear a few opinions.

I'm writing a control panel for an application that runs separately. The
control panel is basically (almost) fully self contained. It consists of a
tabbed pane with 5 different tabs. Each tab has a number of different
controls -- basically all the "commonly used" controls (buttons, lists,
comboboxes, text input...). For a number of components it is easiest for
me to use anonymous or other inside classes. I'm also using private
classes (each tab pane is created by a private class in the same file as
the main GUI class).

So for a project like this, do most people write the code for the entire
window as 1 class, or a separate class for each panel? Is there any kind
of guideline about when a class gets too big? It seems to me any class
creating a window and adding controls will be rather large, since so many
things are done for each component (specifying min, max & preferred size,
adding listeners, specifying list objects, etc), so I would think almost
any class that contains a window would be big anyway.

So how would other people determine what goes in one class and in another,
or if they use private classes in a case like this?

Thanks!

Hal

[John Court]

Re: GUI Classes -- How Big? A Question of Style...

"Hal Vaughan" <hal@thresholdd igital.com> wrote in message
news:Js87b.2932 35$Oz4.81794@rw crnsc54...[color=blue]
> I think a lot of this is definately a question of personal programming
> style, but I'm new to Java and would like to hear a few opinions.
>
> I'm writing a control panel for an application that runs separately. The
> control panel is basically (almost) fully self contained. It consists of[/color]
a[color=blue]
> tabbed pane with 5 different tabs. Each tab has a number of different
> controls -- basically all the "commonly used" controls (buttons, lists,
> comboboxes, text input...). For a number of components it is easiest for
> me to use anonymous or other inside classes. I'm also using private
> classes (each tab pane is created by a private class in the same file as
> the main GUI class).
>
> So for a project like this, do most people write the code for the entire
> window as 1 class, or a separate class for each panel? Is there any kind
> of guideline about when a class gets too big? It seems to me any class
> creating a window and adding controls will be rather large, since so many
> things are done for each component (specifying min, max & preferred size,
> adding listeners, specifying list objects, etc), so I would think almost
> any class that contains a window would be big anyway.
>
> So how would other people determine what goes in one class and in another,
> or if they use private classes in a case like this?
>
> Thanks!
>
> Hal[/color]

I would probably use a class for the "parent" window with the tabbed pane
and use a separate class for each of the 5 options. These will share
characteristics so I would probably use a common superclass for these 5 to
avoid retyping the same stuff 5 times. I don't know of any particular
guidelines, but I seldom write a class larger than 500 lines. I also tend to
move actionlisteners into a separate class to avoid mess. I would also
recommend using private classes sparingly. I find it much easier to deal
with them separately.

John


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003

[Phil...]

Re: GUI Classes -- How Big? A Question of Style...

I have done this sort of thing only once and I use
a separate class for each tab. I like to keep my files
relatively small too, but the guy I work with keeps
making huge files that go on forever.

"John Court" <-> wrote in message
news:3f7138c8$0 $10969$fa0fcedb @lovejoy.zen.co .uk...[color=blue]
> "Hal Vaughan" <hal@thresholdd igital.com> wrote in message
> news:Js87b.2932 35$Oz4.81794@rw crnsc54...[color=green]
> > I think a lot of this is definately a question of personal programming
> > style, but I'm new to Java and would like to hear a few opinions.
> >
> > I'm writing a control panel for an application that runs separately.[/color][/color]
The[color=blue][color=green]
> > control panel is basically (almost) fully self contained. It consists[/color][/color]
of[color=blue]
> a[color=green]
> > tabbed pane with 5 different tabs. Each tab has a number of different
> > controls -- basically all the "commonly used" controls (buttons, lists,
> > comboboxes, text input...). For a number of components it is easiest[/color][/color]
for[color=blue][color=green]
> > me to use anonymous or other inside classes. I'm also using private
> > classes (each tab pane is created by a private class in the same file as
> > the main GUI class).
> >
> > So for a project like this, do most people write the code for the entire
> > window as 1 class, or a separate class for each panel? Is there any[/color][/color]
kind[color=blue][color=green]
> > of guideline about when a class gets too big? It seems to me any class
> > creating a window and adding controls will be rather large, since so[/color][/color]
many[color=blue][color=green]
> > things are done for each component (specifying min, max & preferred[/color][/color]
size,[color=blue][color=green]
> > adding listeners, specifying list objects, etc), so I would think almost
> > any class that contains a window would be big anyway.
> >
> > So how would other people determine what goes in one class and in[/color][/color]
another,[color=blue][color=green]
> > or if they use private classes in a case like this?
> >
> > Thanks!
> >
> > Hal[/color]
>
> I would probably use a class for the "parent" window with the tabbed pane
> and use a separate class for each of the 5 options. These will share
> characteristics so I would probably use a common superclass for these 5 to
> avoid retyping the same stuff 5 times. I don't know of any particular
> guidelines, but I seldom write a class larger than 500 lines. I also tend[/color]
to[color=blue]
> move actionlisteners into a separate class to avoid mess. I would also
> recommend using private classes sparingly. I find it much easier to deal
> with them separately.
>
> John
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.520 / Virus Database: 318 - Release Date: 18/09/2003
>
>[/color]

[Fred]

Re: GUI Classes -- How Big? A Question of Style...

"John Court" <-> wrote in message
[color=blue]
> I would probably use a class for the "parent" window with the tabbed pane
> and use a separate class for each of the 5 options. These will share
> characteristics so I would probably use a common superclass for these 5 to
> avoid retyping the same stuff 5 times. I don't know of any particular
> guidelines, but I seldom write a class larger than 500 lines. I also tend to
> move actionlisteners into a separate class to avoid mess. I would also
> recommend using private classes sparingly. I find it much easier to deal
> with them separately.
>
> John[/color]

That's an interesting approach. I wonder, if you have a separate
class for your action listener, and it needs to reference other
information on the UI, how do you pass along that information?

For a contrived example, you have a textbox for text, a textfield for
a filename, and a "save" button. So the actionListener for the button
is in a separate class. That's fine... but then you have to set
fields within the action listener class so that it can access the
textbox and textfield, or some other similar overhead (not that that's
a whole lot of overhead).

My approach is either that it's an independent operation, in which
case I might extend JButton with a class that implements
actionListener, or when everything is somehow related, I have my GUI
class implement the actionListener (especially in this case - where
there's only one thing listening anyway). Now, the GUI class, in this
case, might just be another compound component - one of the tab panes,
for example. I have some programs that do database work and I have a
reusable component to display the records in a JTable with options to
refresh the display or remove a record - I use this in several
programs. It's simple enough that (with only two buttons), that I
implemented the actionListener within that class, and just check to
see which button was pressed.

I guess what I'm saying is that I wouldn't always do it the same way,
I'd have to know more about the context of the program. I like to
think of things as either being related (in which case I might put the
actionListener within the GUI class) or as being independent (in which
case I might put it in a separate class). But if I were putting it in
a separate class, I'd just implement my own component - extending a
component and implementing an actionListener. Then that makes for
reusable components.

For this example, the five tab panes, I'd have to know more, but I'd
probably at least put each pane in a separate class, and if they are
simple enough I'd implmenet the actionListener within the class. Just
my $0.02.

[Charlie]

Re: GUI Classes -- How Big? A Question of Style...

Hal,

Large classes are very complicated, and hard to understand. Primarily
because there is a lot of code and it's doing lots of things.
Further, everything in your program has access to everything else.
This sort of design makes it hard to change things without have other
dependancies that must also change. Smaller classes do less things,
and are easier to understand and maintain. If there's not a lot of
code there then it can't be doing to much.

Your question is a very good question to ask. If you look at all the
Swing books out there, they're more concerned with telling you the API
than best practices or how to make the API easy to use. Very few
people seemed to know how to structure Swing apps so that it's easy to
change and modify them.

I would recomend you seperate your classes in logical units.
Everything dealing with X in one "place", and everything dealing with
Y in another. In your program X and Y might be subclasses of panels
or classes that contain the components in 1 of the 5 tabs. When I say
place I mean a class or a set of related classes. Now what glues X
and Y together, so that it creates a complete program, should be the
responsiblity of another class. Generally, this is called the
controller in MVC terms. He should be in charge of creating instances
of X, Y, and maybe some high level actions. In your program he'd
probably create the tabs and the JFrame. He should also control the
model for your program. Then he can hand the right parts of the model
to each view component or control access to it. Should he be adding
listeners on the sub panels or controls within X and Y? Probably not.
Let the X and Y be responsible for responding to changes in their UI,
and have them call a method on the controller in order to accomplish
the business logic and manipulate the model. Seperating these
concerns from each other makes it esaier to modify the internals of X
or Y without impacting any other part of your program.

It doesn't sound like your program is too complicated, but it's good
that you're thinking about these sorts of issues. I have been doing
Swing for 4 years now, and I learned all of this the hard way.

good luck
charlie

Hal Vaughan <hal@thresholdd igital.com> wrote in message news:<Js87b.293 235$Oz4.81794@r wcrnsc54>...[color=blue]
> I think a lot of this is definately a question of personal programming
> style, but I'm new to Java and would like to hear a few opinions.
>
> I'm writing a control panel for an application that runs separately. The
> control panel is basically (almost) fully self contained. It consists of a
> tabbed pane with 5 different tabs. Each tab has a number of different
> controls -- basically all the "commonly used" controls (buttons, lists,
> comboboxes, text input...). For a number of components it is easiest for
> me to use anonymous or other inside classes. I'm also using private
> classes (each tab pane is created by a private class in the same file as
> the main GUI class).
>
> So for a project like this, do most people write the code for the entire
> window as 1 class, or a separate class for each panel? Is there any kind
> of guideline about when a class gets too big? It seems to me any class
> creating a window and adding controls will be rather large, since so many
> things are done for each component (specifying min, max & preferred size,
> adding listeners, specifying list objects, etc), so I would think almost
> any class that contains a window would be big anyway.
>
> So how would other people determine what goes in one class and in another,
> or if they use private classes in a case like this?
>
> Thanks!
>
> Hal[/color]

[Hal Vaughan]

Re: GUI Classes -- How Big? A Question of Style...

Thanks to all those who responded (I can't respond to the original now, it's
off my server -- I've been off line and on Gilligan's Island -- no light,
no power, no 'lectricity, just like Robinson Crusoe -- thanks to Isabel and
9 days without power!). There are some really helpful points and answers,
not just on this response, but in the other branch of this thread.

I am almost completely self-taught (I took a few courses back in the early
80s, but that was mainly FORTRAN and Assembler), so I've been picking up
things like structured programming on my own and it is really helpful to
hear other people talk about how they do things.

Thanks for the comments!

Hal