Swing coding style - comments appreciated

S

stroker_ace

Hi,

I am new to swing and am writing which consists of a main window
(extended JFrame) and several child windows (Extended JDialog)

Virtually all of my class functionality seems to be contained within
anonymous inner classes.

As a result each (outer) class in my GUI tends to have a large
constructor (crwating components and assigning (anoymous inner class)
listeners) and virtually no methods.

Can anyone comment on whether this is good or bad style?

My approach seems sensible to me because component listeners are highly
tailored to the functionality of the component in question and should
probably not be instantiable by other components.

Cheers

Lawrie
 
E

Eric Sosman

Hi,

I am new to swing and am writing which consists of a main window
(extended JFrame) and several child windows (Extended JDialog)

Virtually all of my class functionality seems to be contained within
anonymous inner classes.

As a result each (outer) class in my GUI tends to have a large
constructor (crwating components and assigning (anoymous inner class)
listeners) and virtually no methods.

Can anyone comment on whether this is good or bad style?

My approach seems sensible to me because component listeners are highly
tailored to the functionality of the component in question and should
probably not be instantiable by other components.

This seems a fairly typical outcome: You build the GUI,
make it visible, and then let the listeners take care of
business thereafter.

One thing you might want to consider is making the
listeners themselves "small" by moving the computational
logic into a separate GUIModel class. The test for "Where
does this code belong?" comes down to "If it's about managing
the GUI components it belongs in the listeners; if it's about
managing the data it belongs in the model." For example,
popping up an "INVALID DATA" dialog would be the job of a
listener somewhere, but determining the validity of the data
would be the model's job. The separation introduces some
overhead and creates some artificial barriers, but those
barriers turn into advantages if you later decide to redesign
the GUI: since all the decisions are out of harm's way in the
model class, you can replace the "INVALID DATA" dialog with
a beep and a red border quite easily.
 
C

Chris Smith

I am new to swing and am writing which consists of a main window
(extended JFrame) and several child windows (Extended JDialog)

Virtually all of my class functionality seems to be contained within
anonymous inner classes.

As a result each (outer) class in my GUI tends to have a large
constructor (crwating components and assigning (anoymous inner class)
listeners) and virtually no methods.

Can anyone comment on whether this is good or bad style?

In addition to Eric's comments, I'll add this. It's never good style to
have a very long method, at least in code that is created or maintained
by hand. (Output from code generators -- so long as it's not the sort
of thing you'd check into a source repository or open in an editor -- is
another matter.)

To work around the long method problem, you can just create private
methods that are called from the constructor. For example, you might
have something like this:

public MyGUIPanel()
{
setLayout(new BorderLayout());

add(buildTopBar(), BorderLayout.NORTH);
add(buildContentArea(), BorderLayout.CENTER);
add(buildButtonBar(), BorderLayout.SOUTH);
}

private Component buildTopBar()
{
JPanel panel = new JPanel(new FlowLayout(FlowLayout.LEFT));

...

return panel;
}

and so forth.

Another option to consider is to use a config file based GUI creator
framework. In this case, your listeners would be named classes, and you
wouldn't build your own classes to represent GUI components at all;
you'd just call a method and pass it the resource name for a config file
that you previously built with a GUI creator tool. These kinds of tools
are getting more powerful these days, and represent a decent approach to
creating simple user interfaces when business logic is the true point of
the app. UI-intensive apps, on the other hand, will almost certainly be
poorly suitied for this approach.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
R

Roedy Green

As a result each (outer) class in my GUI tends to have a large
constructor (crwating components and assigning (anoymous inner class)
listeners) and virtually no methods.

You might like to look into trampolines as a technique for cutting
down the number of inner classes. Mainly you do that as an
optimisation technique to cut the RAM overhead, but have a look anyway
to see if it is applicable to making your code easier to maintain.

See http://mindprod.com/jgloss/trampoline.html
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top