Question

如何管理听众等？我发现只有一个按钮等的例子。

我可以考虑以下选项：

每个人的额外课程 - 似乎不对，特别是在项目时可以动态创建
每个组的类（例如form1， form2，controlButtonsOnLeft，controButtonsOnRight，mainMenu， userMenu，...）我将检查哪个按钮/组件导致了这个问题（例如通过getSource方法）
一些超级（大小）控制器，这将接受所有用户操作
每个新的匿名类，这将调用带有参数指定的控制器方法细节（可能是枚举）

另一个问题：我找到了许多MVC的例子，我想知道什么是更好（或常用）的应用程序。由1人开发（应用程序不会很大）？

一个。 Viewer将侦听器设置为控制器（A1-3）

B中。控制器调用查看器的方法，它接受监听器作为参数（方法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

说实话，问题归结为一些问题......

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

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

如果我不需要（侦听器的）可重用性或可配置性，那么匿名内部类通常是首选。它隐藏了功能，并且不会使用一次性小的类来混乱源代码。您应该注意它可以使源代码难以阅读。这当然假定该任务是专门构建的（它是一个单独的，孤立的案例）。通常情况下，在这些情况下，我更愿意从侦听器中调用实际执行工作的其他方法，这样可以为类提供一定的灵活性和可扩展性。您经常发现自己想要修改组件的行为只是为了找到隐藏在匿名或私有内部类中的行为......

如果你想要可重用性和/或可配置性 - 也就是说，监听器执行一个可以在整个程序中重复或通过库重复的常见任务，那么你需要为该任务提供专用的类。同样，我赞成一个自包含的解决方案，所以任何一个监听器只做一个工作，更容易改变一个监听器，然后不得不挖掘if-else语句的复合列表：P

这也可以是一系列abstract个侦听器，可以为类似的操作构建功能，例如从表中删除行......

您可以考虑Action API之类的内容（有关详细信息，请参阅How to Use Actions），这些内容是自包含的工作单元，但也带有配置信息。它们设计用于按钮，例如JButton和JMenuItem，但也可以与键绑定一起使用，使它们非常通用......

你问的第二部分（关于MVC）取决于。我更喜欢在视图中保持与UI相关的功能，并尽可能地保持在控制器之外。我不想让控制器直接将侦听器设置为组件，而是为控制器/视图交互提供我自己的专用侦听器，它通知控制器它可能想知道的视图的更改，反之亦然。

以这种方式思考。您可能有一个登录控制器和视图，但控制器只关心从视图中获取凭据并在视图发出请求时对它们进行身份验证，它不关心如何从views透视图发出请求。这允许你为不同的情况设计不同的视图，但只要你保持视图和控制器之间的契约，它就没有任何区别......但那只是我。

Java Swing GUI用户操作处理

1 个答案: