Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Need Menu design/coding tips

 
Serge Plourde
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I am fairly new to Java programming, but experienced programmer
in xBase languages. In some of those "visual oop" languages,
the components such as menus and menu items are "self-contained"
i.e. they handle their own events.
I'm starting an application and as I add functionalities (menus
and menu items) basing my coding on some samples that I read,
and using one single menuHandler, I find that the code is
becoming too hard to follow, within a single source code file.
My question is what is the best way to handle this?
1. Create one single file per menu/menuItem component and
handle events from within.
2. Create individual menu/menuItem component source code
files; with associated event handlers in separated files
(classes).
3. Extend menu/menuItem classes to create specific
Menu/menuItems (such as "File", "Open", "Save", "Save as...")
and override their event dispatching methods.
What is the most "professional" approach to that?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, there's probably a variety of opinions on this. But personally, I try to keep the GUI in a separate class from the underlying functionality. That way I can change the GUI around more easily without disturbing the underlying funtionality, or even use a command-line interface instead of GUI, and still be able to use the program. Also it's much easier to write tests of non-GUI components.
Aside from the keeping the non-GUI stuff separate from the GUI, I'm pretty happy putting all the GUI for a single frame/dialog/whatever in a single class file, as long a it doesn't get too big. The key is to keep all code for a particular component in one place as much as possible. Here's a simple example:

<code><pre>
public class MyFrame extends Frame {

public MyFrame() {
...
setLayout(someLayout);
add(makeSomeButton());
add(makeSomeOtherButton());
add(makeDoCalculationButton());
...
}

...

private Button makeDoCalculationButton() {
Button button = new Button("Do Calculation");
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
underlyingObject.doCalculation();
}
});
return button;
}

...
}
</pre></code>
Most of the code pertaining to a given component (the "Do Calculation" button in this case) is in a single method, makeDoCalculationButton(). It's a private method that only gets called once, but it's a convenient place to put most of the code relating to that component. The connection to the underlying processing that is supposed to be done by this button is made in the anonymous ActionListener. I don't want to see any details of how the calculation is performed here; that would distract me from my GUI-related code here. Just a simple call to whatever object does know the details. The only other code related to the component that I don't want to put inside the make method, is the code that establishes where that component is going to appear in my GUI, usually an add() call putting the component in a Container of some sort. I keep that separate, because to understand the container I need all of its add() statements in one place.
So for menus, my code might look something like this:
<code><pre>
class MyFrame {
public MyFrame() {
...
setMenuBar(makeMenuBar);
...
}

private MenuBar makeMenuBar() {
MenuBar menuBar = new MenuBar();
...
menuBar.add(makeMenuA());
menuBar.add(makeMenuB());
menuBar.add(makeMenuC());
...
return menuBar;
}

private Menu makeMenuA() {
Menu menu = new Menu();
...
menu.add(makeMenuItemA1());
menu.add(makeMenuItemA2());
menu.add(makeMenuItemA3());
menu.add(makeMenuItemA4());
...
return menu;
}

...

private MenuItem makeMenuItemA1() {
MenuItem item = new MenuItem("A1");
...
item.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
otherObject.doA1();
}
});
...
return item;
}

private MenuItem makeMenuItemA2() {
MenuItem item = new MenuItem("A2");
...
item.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
otherObject.doA2();
}
});
...
return item;
}

...
}
</pre></code>
Note that each of these makeXXX() methods could be made into a separate class if we desire - useful if the class is getting too big to be easily readable. For example MenuA could be a class, whose constructor replaces makeMenuA(). The class would also contain the other makeXXX() methods used by menu A - makeMenuItemA1(), A2, etc. It's easy to break into separate classes later if you kept the code organized logically in the first place.
I hope that helps. Obviously there are many ways to do this, but this one works well for me.
 
Serge Plourde
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot Jim!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!