Java Swing GUI 用户操作处理

Question

应该如何管理监听器等？我只找到了带有一个按钮等的示例。

我可以想到以下选项:

1. 为每个人提供额外的类(class) - 似乎不对，尤其是当项目可以动态创建
2. 每个组的类(例如 form1、form2、controlButtonsOnLeft、controlButtonsOnRight、mainMenu、userMenu，...)我将在其中检查哪个按钮/组件导致了此问题(例如通过 getSource 方法)
3. 一些 super (尺寸) Controller ，它将接受所有用户操作
4. 每个新的匿名类，它将调用 Controller 的方法并指定参数详细信息(可能是枚举)

还有一个问题:我找到了很多 MVC 的例子，我想知道什么对于应用程序来说更好(或常用)。由 1 人开发(应用程序不会很大)？

A.查看器向 Controller 设置监听器(A1-3)

B. Controller 调用查看器的方法，该方法接受监听器作为参数(方法 addLoginSubmitListener、addControlBoldButtonListener 等)

以上都是可以实现的，目前为止我会选择B4。意思是在控制中我会做这样的事情:

...
viewer.addLoginButtonListener(new Listener()
{
  @Override
  public void actionPerformed(ActionEvent e) {
    ...
    someButtonsActionHandler(SomeButtonEnum, ActionEnum);
    ...
  }
});
...
private void LoginActionHandler(LoginElementsEnum elem, ActionEnum action)
{
  if (elem.equals(LOGINBUTTON)) {...}
  ...
}
...

这结合了可读代码(代码中的一个位置有 1 个逻辑部分)，不会创建任何不需要的冗余代码，不需要任何几乎动态的检查，易于重用等等。您能确认/评论这个解决方案吗？

Answer 1

说实话，这个问题归结为很多问题......

• 您想要可重用性吗？
• 您想要可配置性吗？
• 它们是独立的吗？也就是说，其他人监听该组件是否有意义，或者将来需要修改监听器的结果操作吗？

就我个人而言，我倾向于 self 遏制。给定操作/任务的单个监听器。这使得我可以在需要时更轻松地进行管理和更改。

如果我不需要(监听器)的可重用性或可配置性，那么匿名内部类通常是首选。它隐藏了功能，并且不会因小型的、一次性使用的类而使源代码变得困惑。您应该注意，它可能会使源代码难以阅读。当然，这假设该任务是专门构建的(它是一个单独的、孤立的案例)。通常，在这些情况下，我更愿意从监听器中调用实际完成工作的其他方法，这为类提供了一定的灵 active 和可扩展性。很多时候，您发现自己想要修改组件的行为，却发现该行为隐藏在匿名或私有(private)内部类中......

如果您想要可重用性和/或可配置性 - 也就是说，监听器执行可以在整个程序中或通过库随时间重复的常见任务，那么您将需要为该任务提供专用类。同样，我更喜欢一个独立的解决方案，因此任何一个监听器只做一项工作，更改单个监听器比必须挖掘 if-else 语句的复合列表要容易得多:P

这也可以是一系列抽象监听器，它们可以构建类似操作的功能，例如从表中删除行......

您可以考虑类似 Action API(请参阅 How to Use Actions 了解更多详细信息)，它们是独立的工作单元，但也带有配置信息。它们被设计为与按钮一起使用，例如 JButton 和 JMenuItem ，但也可以与键绑定(bind)一起使用，这使得它们非常通用......

你问题的第二部分(关于 MVC)取决于。我更喜欢尽可能将 UI 相关功能保留在 View 中并保留在 Controller 之外。我不想让 Controller 直接为组件设置监听器，而是更愿意为 Controller / View 交互提供我自己的专用监听器，该监听器通知 Controller 它可能想了解的 View 更改，反之亦然。

这样想吧。您可能有一个登录 Controller 和 View ，但 Controller 只关心从 View 获取凭据并在 View 发出请求时对它们进行身份验证，它不关心从 View 角度如何发出该请求。这允许您针对不同的情况设计不同的 View ，但是只要您维护 View 和 Controller 之间的契约，就不会产生任何区别......但这只是我的想法。