Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Swing coding style - comments appreciated

Reply
Thread Tools

Swing coding style - comments appreciated

 
 
stroker_ace@hotmail.com
Guest
Posts: n/a
 
      09-22-2005
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

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      09-22-2005


http://www.velocityreviews.com/forums/(E-Mail Removed) wrote On 09/22/05 07:26,:
> 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.

--
(E-Mail Removed)

 
Reply With Quote
 
 
 
 
Chris Smith
Guest
Posts: n/a
 
      09-22-2005
<(E-Mail Removed)> wrote:
> 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
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      09-22-2005
On 22 Sep 2005 04:26:56 -0700, (E-Mail Removed) wrote or quoted
:

>
>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
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Coding Practices, suggestions, feedbak appreciated Alejandro Aleman MCSD 0 04-23-2006 07:57 PM
general coding issues - coding style... calmar Python 11 02-21-2006 10:36 AM
Help or comments appreciated. Brad Jones ASP .Net 4 05-19-2005 03:18 PM
comments much appreciated - thank you for your help windandwaves HTML 18 03-19-2005 08:10 AM
CSS problem with IE6. Comments and advice appreciated Deryck HTML 7 06-12-2004 01:32 PM



Advertisments