Swing: Buttons and Listeners

When it comes to programming, I love research. Research allows me to explore new possibilities and see how other programmers implement different aspects of UI design. One of those areas is how programmers wire up their buttons and listeners to produce loosely coupled application components. While there are probably many ways to wire up buttons and listeners, here are some that appear to be common.

Please note: The following code has not been tested, they are merely hand written examples.

The Anonymous Class

The anonymous class is the first implementation that I learned. It is taught in most introductory texts and is possibly the most basic. This is an inline implementation.

A new anonymous class is created that implements the ActionListener interface.

The nice thing about this implementation is that it is fairly simple. The downside is that the code isn’t all that flexible or reuseable.

The “this” reference.

As mentioned in the previous example the anonymous class implements the ActionListener interface – which specifies the implementation method ActionPerformed.  So long as a class implements this method then it can be added to the button as a registered action listener.

The key parts in this implementation is that the class now implements the ActionListener interface, and must now include a ActionPerformed method to fulfill the interface’s contract. By adding a reference of this to the button, the button calls the ActionPerformed method of the object, which specifies what action is to be performed.

This too is a basic implementation that is often used in introductory texts, however, it isn’t something I see too often. And limits the flexibility of the class.

Often when you want some button to take some action, it is not within the class itself, but often in a seperate class or component. This presents a downside, whatever object or component you want to affect, then the class must include a reference to that object. This could result in tightly coupled components.

In this example, we have passed in a reference to a JTextArea object – which could be passed in by a controller class. But the point is that the class now has a reference to the textArea object, and needs a JTextArea object to function. This means that the class and the JTextArea are tightly coupled.

The Interface Stand In

In order to decouple the class from TextArea component, we can use a custom interface to stand in.

This interface just specifies one method that implementers must implement. It takes a string as an argument.

By substituting the textArea for an interface, we can decouple the class from the textArea, and move it to a more appropriate place such as a controller class. We can also specify what action the interface implements when we set up the interface.

Here, when we set the StringListener in the ToolBar object, we create an anonymous class that implements the emitString method specified by the StringListener interface. And here we have specified what that method would do when it is called. In this case, it appends the text to the textarea specified in the controller class.

We have now successfully decoupled the textArea from the toolbar class by using an interface.

The beauty of this method is that you can now pass in any object that implements the StringListener interface.

The Inner Class

One method that I use often (although probably incorrectly) is to use a series of inner classes that exist within the controller class. These inner classes implement the ActionListener interface and then added to the button’s action listeners via a public method.

This allows me to help organize my listeners and the actions it perform within the controller class. However, having recently learned of the interface stand in variety of implementing buttons and listeners I may have to revisit some of my old code and see if it is a more appropriate option.

In fact, despite now having described four different ways to implement buttons and listeners, each one has it merits and flaws, and as far as I can tell there is no one best way to do it, rather you have to look at each case individually and decide what is most appropriate for your project at that particular time and stage of development. Learn them all.

Btw, I am really loving the Crayon Syntax highlighter plugin I just discovered for wordpress. Isn’t it just pretty?

Comments are closed.

Powered by WordPress. Designed by Woo Themes