CODEWITHSUNDEEP
javaswinguser-interface
rhbrb
rhbrb

Reputation: 139

How To Structure a Swing Application

I don't really have much experience with swing, or GUI design in general for that matter (a few WPF applications in university is about the height of it), however I have been tasked with refactoring part of a swing legacy application at work.

The part I've been asked to refactor revolves around a popup window which can display in three different formats depending on a certain value object. These 3 different formats all share a few base fields, and then have additional ones determined conditionally. The class responsible for this GUI element is ~5k long and I was thinking it should be split into three subclasses, with the shared stuff in base class which they all extend. However I have absolutely no idea if this is the correct approach or not.

Could anyone highlight some strategies used in dealing with different swing components which share elements such as buttons/fields etc?

Additionally, are there any large OSS swing applications which can be used to learn from?

More info: The application I am working on is a large legacy application which is rather horrifically structured at the moment. I'm new to the team (and a fairly recent grad so don't have much experience in this area) and have been asked to try and break down one of the huge classes which is responsible for the display of this popup at the moment into smaller more maintainable components. Essentially there is a pop up in the application which allows the user to respond to certain events, and this has three different appearances depending on the sub type of the request they need to respond to. A large portion of the GUI elements are consistent across all three sub types, as such I am interested to know if inheritance would be the best approach here or are there other strategies for dealing with this?

Upvotes: 8

Views: 10337

Answers (2)

sdasdadas
sdasdadas

Reputation: 25096

What if you were to set up an abstract class that creates the 50% shared code, and then extend from that?

For example:

abstract class BasePopupPanel extends JPanel {

    public void initialize() {
        // Initialize all the shared code here.
        // eg. add(new JButton("TEST");
    }
}

And now you create the actual popup panels:

public class GiraffePopupPanel extends BasePopupPanel {

    public void initialize() {
        super.initialize();
        // Here you do all the initializations for this class.
    }
}

You can create as many of these as you would like. When it comes time to add them...

...let's say you have a method that is called displayPopup, then the signature would look like this:

public void displayPopup(BasePopupPanel popup) {
    // do stuff regarding JDialogs, etc.
    // ...
    popup.initialize();
    // do more stuff...
}

I hope that gives you one view on how you could refactor your classes.

Upvotes: 2

Gilbert Le Blanc
Gilbert Le Blanc

Reputation: 51445

Reading the comments, I think I can answer this question. A true answer would require a book.

  1. Break up your GUI into as many nested JPanels as it takes to describe your GUI. A simple nested JPanel that uses a BorderLayout is preferable to a complicated JPanel that uses a GridBagLayout. To be clear, I'm not criticizing a GridBagLayout. It's useful when creating a form. But it's not the only Swing layout manager.

  2. Put each nested JPanel into its own class.

  3. Use composition when using Swing components. Use inheritance if and only if your class will override one of the JComponent methods.

  4. Each JPanel has its own JButton, JLabel, etc. components. JBUtton A is defined for JPanel A, and JButton B is defined for JPanel B, even if the user of the GUI thinks they are the same button. You can minimize the duplication by creating a GUI model that contains the text of the labels and buttons. You must eliminate the duplication of action code (the code that's executed when the button is pressed) by writing common ActionListeners that JButton A and JButton B can execute.

  5. A Swing application must start with a call to SwingUtilities.invokelater(). This ensures that the Swing components are defined and used on the Event Dispatch thread (EDT).

  6. Only one JFrame is used in a Swing application.

  7. Each JPanel must have a Swing layout manager defined.

  8. Certain components, like JList and JTable, work better when enclosed in a JScrollPane.

I'm sure I've forgotten a few things, but this should be a good start.

Upvotes: 20

Related Questions