我不擅长 GUI 设计。经过深思熟虑、研究和实验，我开发了几个设计理念，但仍然没有一个看起来有效。一种设计有一个 Session 上帝对象在创建时在每个 UI 元素上注册一个侦听器，每个关心任何操作的对象都会在 Session 对象上注册一个侦听器。这看起来简单而强大，因为所有消息传递都通过一个中心位置，因此丢失任何东西的可能性较小。虽然这是蛮力，而且看起来很麻烦且效率低下。
另一种设计试图创建相互对话的对象子组。这避免了巨大的顶级 Session 并且看起来更高效，但也似乎容易出错。
我正在尝试实现一个可重用的框架，在该框架中，我将具有相关目的的按钮分组到工具栏中，并采用分层方法来侦听工具栏执行的操作以及与侦听器相关的操作。到目前为止，我已经做到了：
public class EditorToolBar extends JToolBar {
public static enum Command {
ZOOMIN,
ZOOMOUT,
FINER,
COARSER,
RESET
}
private ButtonCommandListener listener = new ButtonCommandListener();
public EditorToolBar() {
super("Editor Commands");
JButton button;
for (final Command cmd : Command.values()) {
button = new JButton(cmd.toString());
button.setEnabled(true);
button.setToolTipText(cmd.toString() + " Command");
button.setActionCommand(cmd.toString());
button.addActionListener(listener);
add(button);
}
}
public void addActionListener(ActionListener pNewListener) {
listener.cActionNotifier.addListener(pNewListener);
}
private class ButtonCommandListener implements ActionListener {
private NotifierImp<ActionListener> cActionNotifier = new NotifierImp<ActionListener>();
public void actionPerformed(ActionEvent pEvent) {
for (ActionListener listener : cActionNotifier) {
listener.actionPerformed(pEvent);
}
}
}
} // class EditorTooBar
和听众实现这样的事情：
public void actionPerformed(ActionEvent pEvent) {
switch (EditorToolBar.Command.valueOf(pEvent.getActionCommand())) {
case ZOOMIN:
// do something
break;
case ZOOMOUT:
// do something
break;
case FINER:
// do something
break;
case COARSER:
// do something
break;
case RESET:
// do something
break;
default:
System.out.println("Unknown EditorToolBar Command: "+pEvent.getActionCommand());
return;
}
我可以增强枚举的讲师，使其还包括工具提示文本、图像等。我想重用这个设计，只是用一个不同的枚举来描述其他工具栏。侦听器将使用 ActionEvent.getActionCommand() 和使用 Command.toValue(String) 来区分不同的按钮操作。我希望将其扩展到正在侦听的类的层次结构：超类可以为一种类型的工具栏实现侦听器，而子类通过侦听不同的工具栏类型来添加该侦听器。如果事件不是来自子类感兴趣的工具栏，它可以将事件转发给超类。为了完成这项工作，我需要一种方法来区分一个工具栏和另一个工具栏，但最好不必检查该工具栏上可能出现的每个按钮事件。理想情况下，我想要一个工具栏工厂，并且仅指定一个枚举就足以完全描述一个工具栏。无法对枚举进行子类化增加了这里的挑战。
这是一个有前途的设计模式吗？我还没有在其他地方看到它。有没有更好的方法我应该使用而不是发明劣质的东西？欢迎提供其他选项的链接。
编辑：根据 yash ahuja 的回答，我应该澄清一下，当我提到层次结构时，我的意思是类似于处理键绑定的方式（即你有绑定吗？不，那么你的容器有绑定吗？......直到某人消费了关键事件）而不是实际的类层次结构。