Java, large GUI classes, with many ActionListeners; best way to organize listeners?

Question

I have been developing java programs for 1½ years. I am currently working on a summer project that includes a fairly large graphical user interface.

My GUI consists of several tabbed panels. Each panel has its own class. Each panel has several jButtons buttons.

Now I come to the point where in my tabbed classes there were so many anonymous inner classes (for ActionListeners) that I am sure there should be a better way; if not for efficiency, then for maintainability - it becomes quite a mess.

My question is: is it better to organize students when each of them has them in each class? I was thinking about clustering listeners in the appropriate classes - for example, the following code example:

public class SomeListeners implements ActionListener{ @Override public void actionPerformed(ActionEvent e){ String command = e.getActionCommand(); switch(command){ case "This button": doThis(); break; case "That button": doThat(); break; } } } 

Or maybe an even better way?

Thank you in advance:)

Answer 1

You can try the following approach:

Use real classes instead of anonymous classes. Each ListenerClass implements only one use case / functionality. The class name must describe UseCase. You can then organize the classes in one or more packages to group them into categories that match the used cases that the Listener implements in the package.

This means that you are creating an abstraction hierarchy that organizes functions such as a tree structure.

If after some time someone needs to support the Listener, he can find the Listener, first he is looking for a package that is suitable for UseCase, and then for UseCase itself. Since you will have fewer packages, then Classes will be easier and faster to find Listener.

---

Another way to think: if you have so many events on one tab, that you get problems organizing them in code, how do you visualize them on the tab? Can you handle this ergonomically for the user? Maybe the solution could be to split the functionality into more than one Tab? But since I don’t know your user interface, I can’t say too much about it.

Answer 2

I would recommend using one class from the javax.swing.AbstractAction type

Example:

 Action leftAction = new LeftAction(); //LeftAction code is shown later ... button = new JButton(leftAction) ... menuItem = new JMenuItem(leftAction); leftAction = new LeftAction("Go left", anIcon, "This is the left button.", new Integer(KeyEvent.VK_L)); 

...

 class LeftAction extends AbstractAction { public LeftAction(String text, ImageIcon icon, String desc, Integer mnemonic) { super(text, icon); putValue(SHORT_DESCRIPTION, desc); putValue(MNEMONIC_KEY, mnemonic); } public void actionPerformed(ActionEvent e) { displayResult("Action for first button/menu item", e); } } 

Answer 3

Per duffymo: use dependency injection and go to Listeners. This will give you the opportunity to reuse and modify them as you wish.

For me (hovercraft): This should not be Spring, as Guice will work fine. And this will work well with the treeno offer, as well as Tim Herold's offer (1+ to both of them). All this concerns the best possible grip and grip loosening.

Answer 4

At some point, anonymous inner classes move from "convenient" to vicious mess. You have passed this point.

Like Tim, I suggest you use AbstractAction. However, for the extension, create your own abstract subclass that can read its name, icon, description (for tooltips), etc. From the configuration file. This way you can internationalize the code, while others (marketing) can easily change the buttons from “Save” to “SuperSomethingTM” or something else. And a graphic artist can easily change the icon. Extend this class to the actual implementation.

One additional benefit of AbstractAction is that they can be disabled. So, if no changes are saved, you can easily disable the "Save" menu, the "Save" button and the "Save" icon on the toolbar.

There are various ways to store and read this configuration information. One of them is ResourceBundle.

(printed on my Nook, so it's on the short side, others are free to expand)

Answer 5

something like this code

 public class SomeListeners implements ActionListener{ @Override public void actionPerformed(ActionEvent e){ String command = e.getActionCommand(); switch(command){ case "This button": doThis(); break; case "That button": doThat(); break; } } } 

• talk about EventHandler, theoretically any String or their combinations in the hierarchy, the real Componets tree can create void "do" + "Th" + "is" (); , you can compare the required neede characters for a standard ActionListener

• the output from EventHandler should only be a Swing Action, override setEnabled as another parameter in EventHandler

Answer 6

JSR 296 was supposed to provide the basis for what you are doing, and much more that was mentioned here (i18n, Actions, etc.). The most active implementation is the Better Swing Application Framework or BSAF. A good article on how to use any JSR 296 implementation can be found here .