GUI Planning & Design

[Marcus Hathaway]

Hi all, as being quite new to java, i was wondering if any more experienced programmers could offer some advice or tips about how they structure their GUI's in relation to the program. I am comfortable creating GUI's and interacting with data, however, as i begin to write bigger programs i want to ensure that my design is **professional**.

For instance, should the class that actually displays the GUI be entirely separated from the logic (so JButtons etc in one class, whilst event listeners in another, whilst logical methods in another blah blah...!). I've heard of the Model-View-Controller theory for web applications and am trying to implement something similar for my java programs. However, i sometimes find it tricky to keep things entirely separated. For instance, say a combo box is populated with items from a database....how would a professional design this?

Any comments would be greatly appreciated

[Don Kiddick]

Not sure about having your event listeners in a seperate file to your buttons and stuff. It is good though to have your logic in seperate classes (controller classes in MVC?). A heuristic of a good gui design is how easy it would be to add another gui (say SWT 0or text based) to the application. If it�s easy you don�t have much logic code in your view classes.

hth.
D

[Jared Cope]

Hi,

Originally posted by Don Kiddick:
Not sure about having your event listeners in a seperate file to your buttons and stuff.

A lot of this comes down to personal style, but I actually do write a separate class for all listeners that I attach to buttons etc. Even if the resulting listener class is going to be 10 lines, I still take the time to create a class that extends AbstractAction and implement the actionPerformed method.

Doing this gives me the chance to reuse the action and get the same behaviour if I later add a menu item to do the same job as the button. I just add this listener class as the action for the menu item.

Another benefit I like is that I avoid having all those ugly anonomous method local classes so that the main class is easier to read (or I avoid having to force the main class to implement ActionListener and have that ugly switch case statement to figure out where the event came from).

Other than this, I would agree with what Don wrote above.

Cheers, Jared.

[Marcus Hathaway]

Hi guys, thanks for the replys.

I'm interested that you mentioned having different classes for the event listeners. I currently don't do this. However, i don't use switch statements either. Instead i keep using inner classes inside the class for all event actions. Is this a good/bad way to handle things? I find it a lot of effort and work to write entirely differnt classes if the action event needs to be quite specific or complicated. However, i take on board your point about being able to reuse the code...

I guess the reason why i posted originally was because i have been writing classes recently that are 100s of lines of code and in some cases, similar classes have also been 100s of lines of code when perhaps if my design and use of OO was better maybe i could save myself lots of time and work!

I mean....do people ever go as far as writing classes that may, for instance, just return a JPanel or something? Or is this going a bit to far?

[Jared Cope]

Hi,

Originally posted by Marcus Hathaway:

Instead i keep using inner classes inside the class for all event actions. Is this a good/bad way to handle things?
...
i have been writing classes recently that are 100s of lines of code and in some cases, similar classes have also been 100s of lines of code when
...
I mean....do people ever go as far as writing classes that may, for instance, just return a JPanel or something? Or is this going a bit to far?

Some good questions.

1. Inner classes have their place, especially for action listeners on Swing components. I don't think they are bad style. But they can clutter a class file and make it hard to read the flow of the code. For this reason, I like to make them their own class.

For example, I have an action like:

import java.awt.event.ActionEvent;
import javax.swing.AbstractAction;
import com.afx.lanark.LanarkMediator;
 
public class JButtonJustAction extends AbstractAction{
 
    public void actionPerformed(ActionEvent e){
        LanarkMediator.getStoryTextPanel().getHeadlinePanel().justify();
        LanarkMediator.getMainStoryEditor().justify();    
        LanarkMediator.getMainStoryEditor().requestFocus();
    }
}

and I use it like this in the main GUI construction class:

...
JButton button = new JButton("Justify");
button.addActionListener(new JButtonJustAction());
...

Writing my code this way has helped to cut down the size of individual class files. All the code still exists somewhere and has to be written, but doing it this way makes it more managable for me.

2. Yes, I do write methods to return a JPanel with a few components added onto it. Sometimes I make this into its own class. For similar reasons of just breaking up the task of building a GUI into smaller manageable chunks.

I hate having a big long GUI initialization method of hundreds of lines. But I do like having an initialization method that delegates work to (if need be) 10-20 other private helper methods (or even other classes if possible).

Hope this gives you some ideas.

Cheers, Jared.

[Pat Hays]

Hello Marcus

You may try JFrameBuilder, if you have not tried it. It helps Java learner to learn how to GUI in Java.