General Question on GUI Developement

This is more of a general question that a specific issue/bug. I was recently asked to develop my first real GUI application. I have played with Swing before so I am not a total newb. I used Netbeans UI designer to get look and components right, now I am coding the smarts. I seperated the various components into classes, a class for my JTree, a class for my JTable, etc. Now when I am coding, I am finding that everything is tightly coupled and everything needs references to each other. For example, when a user clicks something in the JTree I need to draw a certain table. So the JTree class has a reference to the JTable class and calls the apropriate method to draw the table based on what the user selects. Is this sort of nasty dependency a normal thing in a GUI applications? I tried to be a good developer and break things up into small pieces that do their little task but it seems like everything depends on everything else. Maybe I am just inexperienced and designing this all wrong.

Thoughts?

Message was edited by:

robucf3

[1062 byte] By [robucf3a] at [2007-10-3 2:57:42]
# 1
I tend to keep all the components for a given dialog or frame in the same class so they can interact with one another.
camickra at 2007-7-14 20:47:02 > top of Java-index,Desktop,Core GUI APIs...
# 2
Depending on the application doesn't that make for one huge class?
robucf3a at 2007-7-14 20:47:02 > top of Java-index,Desktop,Core GUI APIs...
# 3

I don't have huge experience under my belt but I've the noticed the same thing as you.. what I would suggest is have the closely coupled classes together (in the same file, using inner classes, if possible). And DON'T try to be too general in your programming.. like coming up with this new class for your program and trying to make it very general (self-contained and isolated). It's not only a waste of time (to put it harshly) but it just isn't tailored to your program.. making it hard to work with, it being so generalized. To be somewhat dramatic, not all classes are to be born equal - some are more suited for generalization while others are not.

Another point which is related to this is that you don't want to break things apart into small independent pieces necessarily. If a bigger piece is more coherent with few external coupling, then that's what you want. You have to get a sense for how to break things up well.

That's my 2 cents.

Max

_maxmkleea at 2007-7-14 20:47:02 > top of Java-index,Desktop,Core GUI APIs...
# 4

And here are my 2 cents:

As always when it comes to questions like this, there is no universally right or wrong answer. It all comes down to your particular application.

If you want to keep your design flexible and open ended, then it makes perfect sense to split up your code into several separate components, and use the Observer pattern and possibly a Mediator to get rid of the tight coupling between them. With this design you can, for instance, easily add new components, or replace your JTable with another component, if need be, without having to touch any other classes. (This becomes especially true if you code to interfaces rather than classes.)

On the other hand, if you are fairly certain that your application will always only have a JTree and a JTable, interacting with each other in a certain way, then it is probably overkill to obfuscate your design like that, and you might as well keep everything tight coupled, either in one single class or in one package.

Torgila at 2007-7-14 20:47:02 > top of Java-index,Desktop,Core GUI APIs...
# 5

Thanks for the replies, its always good to hear other opinions. Reguardless of class size if two things are dependent on each other yeah it makes sense to have them in the same class. The observer pattern does help break up the coupling. Alll very good replies. Thanks. I guess GUI development is just one of those things you learn the do's and don't over time.

robucf3a at 2007-7-14 20:47:02 > top of Java-index,Desktop,Core GUI APIs...
# 6

What you said about not wanting to put everything in the same file has merit. For a large-scale application, the files would become huge.

One way you can manage this is by keeping everything in separate files as you wish, and then having public methods to register action listeners. For instance, say you have a class which extends JPanel and which has a button on it that you want another class in a separate file to respond to the action when the button is clicked.

One way you can do this is by adding a public method which takes an ActionListener as a parameteter and which registers the argument as a listener for that button. This way the outside class can call this method and pass itself as a listener to the button, just as if they were in the same class.

For instance, say you have two classes in separate files, ButtonClass and OutsideClass, the button class containing a JButton and the OutsideClass responding to when that button is clicked. Here is a brief outline of what I mean (remember ButtonClass and OutsideClass are both public so they belong in two separate files):

import java.awt.event.*;

import javax.swing.*;

public class ButtonClass

extends JPanel {

JButton button = new JButton("Click Me");

public ButtonClass() {

add(button);

}

public void addMyButtonListener(ActionListener listener) {

button.addActionListener(listener);

}

public static void main(String[] args) {

JFrame frame = new JFrame();

ButtonClass buttonClass = new ButtonClass();

OutsideClass outsideClass = new OutsideClass();

buttonClass.addMyButtonListener(outsideClass);

frame.getContentPane().add(buttonClass);

frame.setVisible(true);

frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

frame.pack();

}

}

public class OutsideClass

implements ActionListener {

public OutsideClass() {

}

public void actionPerformed(ActionEvent e) {

JOptionPane.showMessageDialog(null, "It worked!");

}

}

TheAndruua at 2007-7-14 20:47:02 > top of Java-index,Desktop,Core GUI APIs...