Project Imperion: New Semantics, Façade and Command Design Patterns for Swing

Project Imperion consists of a library of GUI elements that combine the command and facade design patterns to add new semantic meaning to some common Swing components. This simplifies the synthesis and maintenance of the code. It also shortens the code, while improving readability, speeding synthesis and easing maintenance. It also promotes better code organization, including the separation of business logic from GUI code and a logical grouping of the code along the same lines as its GUI’s appearance. Started in the late ‘90’s, in the DocJava, Inc. Skunkworks, the Imperion project was meant only for menu items using AWT, targeting the single application of image processing programs. It has since been reworked and extended to support the use of 16 Swing components with built-in keyboard shortcuts. The Imperion project was named for the Latin root, imperium, meaning the power to command. 1 WHAT’S WRONG WITH THE CURRENT EVENT MODEL? When programmers use the current event model, they typically jump around in the source code. For example, it is normal for programmers to create a graphic user interface using a 5 step process: 1. Make a new button (or Component) 2. Set the keyboard shortcuts. PROJECT IMPERION: NEW SEMANTICS, FAÇADE AND COMMAND DESIGN PATTERNS FOR SWING 52 JOURNAL OF OBJECT TECHNOLOGY VOL. 3, NO. 5 3. Add the button to the container. 4. Add an ActionListener to the button 5. Create a long dispatch in an actionPerformed method. Visiting code in several places in order to add a feature is a fruitful source of errors. The code is also hard to maintain, and less readable in that the programmer must jump back and forth in the code file to see declarations, installation of components into GUI containers and implementations of event listeners. Such an approach does not scale well. When the number of different components gets large, these jump points can be many lines of code away from one another. To illustrate the programmers’ jumping around in the code, consider the following example: package gui.run.examples; import javax.swing.JButton; import javax.swing.JFrame; import java.awt.Container; import java.awt.FlowLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; public class CommandFrame extends JFrame implements ActionListener { //1. Make the new buttons JButton okButton = new JButton("OK"); JButton cancelButton = new JButton("cancel"); public CommandFrame() { Container c = getContentPane(); //2. Set the shortcuts okButton.setMnemonic('o'); cancelButton.setMnemonic('c'); //3. Add the components to the // container c.add(okButton); c.add(cancelButton); //4. Set up the ActionListeners okButton.addActionListener(this); cancelButton.addActionListener(this); c.setLayout(new FlowLayout()); setSize(200, 200); show(); } public void actionPerformed(ActionEvent e) { WHAT’S WRONG WITH THE CURRENT EVENT MODEL? VOL. 3, NO. 5 JOURNAL OF OBJECT TECHNOLOGY 53 Object o = e.getSource(); // 5. Add to a if-else dispatch if (o == okButton) System.out.println("ok"); else if (o == cancelButton) System.out.println("cancel"); } public static void main(String[] args) { new CommandFrame(); } } Thus, the typical procedure is to put an instance of a button into a class member variable. During the initialization phase for the GUI, the shortcuts are established, components are added to the container and the listeners are added. During the event handling dispatch we check the event to see if it the button was selected. As a result, we have created a situation where we have to visit the code in several places. This complicated procedure for adding code also complicates maintenance and decreases reliability of the program. It also adds more code. The output of the CommandFrame is shown in Figure 1. Figure 1. OK-Cancel Dialog. In addition, using the above formulated actionPerformed method, one can expect a rather long dispatch. As an example, consider the following code, taken from [Lyon 1999]: public void actionPerformed(ActionEvent e) { if (match(e, mandelbrot_mi)) { mandelbrot(); return; } if (match(e, goslab_mi)) { goslab(); return; } // .... 17 if statements later.... if (match(e, systemInfo_mi)) { systemInfo(); return; } super.actionPerformed(e); } PROJECT IMPERION: NEW SEMANTICS, FAÇADE AND COMMAND DESIGN PATTERNS FOR SWING 54 JOURNAL OF OBJECT TECHNOLOGY VOL. 3, NO. 5 Such long dispatches can be exceedingly difficult to maintain. And GUI elements are removed from their definitions by hundreds of lines of code (in programs of only modest complexity). Even more insidious is the invocation: super.actionPerformed(e); This can make reference to an unknown number of concrete super-classes that improve implementation reuse at a cost of increased fragility. In short, such a programming style does not scale well because it does not encapsulate complexity at the right level. The following section shows that adding function points in this way is a waste of time (i.e., unnecessarily difficult and wrong-headed). If you don’t have time to do it right the first time, when will you have time to do it again?