Java GUI App 控制器中的 ActionListener 是个好主意吗? [英] Is ActionListener in controller for Java GUI App good idea?

问题描述

我不想遵循 MVC 模式.在互联网上，我看到最著名的例子是计算器，例如 here.我开始使用MVC模式的这种实现.但是现在我对控制器中的动作侦听器有一些疑问，因为它们倾向于移动到视图中.

有很多与视图相关的更改的主要原因 - 字体、颜色、边框等.此外还有仅修改视图的动作侦听器！因此，在控制器中实现这样的动作监听器要困难得多(与视图中的简单内部匿名类相比).此外，它需要使许多视图元素可以从控制器访问.

我有一个想法，在控制器中保留一些动作侦听器，并在视图中保留一些，但这可能会导致将来混淆.所以我想听听其他人的想法.

I't trying to follow MVC pattern. In internet as I see the most famous example is calculator, for example here. I began to use this implementation of MVC pattern. But now I have some doubts about action listeners in controller as they tend to move to view.

The main reason that there a lot of changes linked to view - fonts, colors, borders etc. Besides there are actionlisteners which modify only view! As a result to implement such actionlistener in controller is much more difficult (comparing to a simple internal anonymous class in view). Besides it requires to make many view element accessible from controller.

I had an idea to keep some actionlisteners in controllers and some in view, but it can lead to confusion in future. So I'd like to hear other people thoughts.

附言这个问题不是 MVC 模式与许多 ActionListeners 的重复

推荐答案

MVC 不是一个严格"的模式.对原始模式有不同的解释，以及不同的派生词，例如 MVP 或 MVVM(即使人们说他们正在使用 MVC).

MVC is not a "strict" pattern. There are different interpretations of the original pattern, and different derivatives like MVP or MVVM that are often used (even when people say that they are using MVC).

最重要的方面是将模型和视图分开.但是关于它们如何连接的细节可能会有所不同，具体取决于应用案例.

The most important aspect is to separate the Model and the View. But the details about how they are connected may vary, depending on the application case.

MVC 模式中最常见的问题是:什么是控制器?"

The most frequent question that arises for the MVC pattern is: "What is a Controller?"

答案:

升职的会计师"

根据我的个人经验，很少有理由拥有一个显式控制器"类.强制在一个控制器"类中累积和汇总监听器有几个严重的缺点.为了在 GUI 组件和模型之间建立连接，您有两种选择:一种选择是允许访问视图组件以附加侦听器:

From my personal experience, there's rarely a reason to have an explicit "Controller" class. Forcing the Listeners to be accumulated and summarized in one "Controller" class has several severe drawbacks. In order to establish the connection between the GUI components and the Model, you have two options: One option is to allow access to the view components in order to attach the listeners:

gui.getSomeButton().addActionListener(myActionListener);

我认为这是不行的，因为它暴露了实现细节并阻碍了修改.另一个选项稍微好一些 - 即提供允许附加侦听器的方法:

I think this is a no-go, because it exposes implementation details and hinders modifications. The other option is slighly better - namely to offer methods that allow attaching listeners:

gui.addActionListenerToSomeButton(myActionListener);

但我认为这是有问题的，因为它仍然暴露了有一个按钮的事实.例如，当您使用 JTextField 输入数字时，问题可能会变得更加明显，然后将其更改为 JSlider:它将更改所需的侦听器类型，虽然这应该只是观点的问题.

But I think that this is questionable, because it still exposes the fact that there is a button. The problem might become more obvious when you have, for example, a JTextField to enter a number, and later change this to be a JSlider: It will change the required Listener types, although it should only be an issue of the view.

在 Swing 应用程序中，我认为 Listeners 可以被视为小控制器".而且我认为让匿名侦听器直接调用模型的方法是完全可行的(除非在这些调用周围有额外的逻辑).

In Swing applications, I think that the Listeners can be considered as "little controllers". And I think it's perfectly feasible to have anonymous listeners that directly call methods of the model (unless there's additional logic to be wrapped around these calls).

话虽如此:我不会将您链接的示例视为 MVC 的好"示例.首先，因为选择的例子没有展示MVC的关键点:模型不包含状态，事实上MVC中的模型通常是必须观察的事情(因此，作为听众附加)并没有变得清晰.其次，由于上述几点，GUI和模型之间建立连接的方式是有问题的.

Having said that: I would not consider the example that you linked as a "good" example for MVC. First of all, because the chosen example does not show the key point of MVC: The model does not contain a state, and the fact that the model in MVC usually is the thing that has to be observed (and thus, as Listeners attached) does not become clear. And secondly, because the way how the connection between the GUI and the Model is established is questionable due to the points mentioned above.

我喜欢 http://csis.pace.edu/~bergin 上的例子/mvc/mvcgui.html .它的某些部分也可能受到质疑(例如，通用 Observer/Observable 类的使用)，但我认为它以一种令人信服的方式很好地展示了 MVC 的基本思想.

I liked the example at http://csis.pace.edu/~bergin/mvc/mvcgui.html . Parts of it could be questioned as well (for example, the use of the generic Observer/Observable classes), but I think that it nicely shows the basic idea of MVC in a convincing way.

编辑:没有以 ZIP 格式下载此示例.但是您可以将 TemperatureModel、TemperatureGUI、FarenheitGUI 和 MVCTempConvert 复制并粘贴到 IDE 中.(它假设存在 CelsiusGUI.这个 CelsiusGUI，在网站上被省略，但在结构上与 Farenheit GUI 相同.对于第一个测试，它所在的行实例化可能只是被注释掉).

EDIT: There is no download of this example in form of a ZIP or so. But you can just copy&paste the TemperatureModel, TemperatureGUI, FarenheitGUI and MVCTempConvert into an IDE. (It assumes a CelsiusGUI to be present. This CelsiusGUI, is omitted on the website, but structurally equal to the Farenheit GUI. For a first test, the line where it is instantiated may just be commented out).

在此示例中，添加侦听器的选项由抽象 TemperatureGUI 类提供.实际侦听器由具体 FarenheitGUI 类创建和附加.但这或多或少是一个实现细节.这里的关键点(也针对原始问题)是侦听器由视图以内部类甚至匿名类的形式创建.这些侦听器直接调用模型的方法.即，以华氏温度设置温度(对于华氏 GUI)，或以摄氏度设置温度(对于摄氏度 GUI).

The option to add listeners is in this example offered by the abstract TemperatureGUI class. The actual listeners are created and attached by the concrete FarenheitGUI class. But that's more or less an implementation detail. The key point here (that also aims at the original question) is that the Listeners are created by the View, in form of inner classes or even anonymous classes. These listeners directly call methods of the model. Namely, to set the temperature in Farenheit (for the Farenheit GUI), or to set the Temperature in Celsius (for the Celsius GUI).

仍有一定的自由度.这不是一个完美"或通用"的 MVC 示例.但恕我直言，它比我迄今为止发现的大多数其他 MVC 示例要好，因为它很好地显示了重要方面:

There are still some degrees of freedom. It's not a "perfect" or "universal" MVC example. But it is IMHO better than most other MVC examples that I found so far, because it shows the important aspects nicely:

1. 模型是Observable
2. View 是一个 Observer
3. 控制器"(即本例中的监听器)是由视图单独维护的匿名/内部类，并调用模型的方法

在更复杂的通用设置中，不会使用 Observable/Observer 类.相反，可以为模型创建专用的侦听器和可能的事件.在这种情况下，这可能类似于 TemperatureChangedListener 和 TemperatureChangedEvent.为了简洁起见，这里使用了 Observable/Observer 类，因为它们已经是标准 API 的一部分.

In a more complex, general setup, one would not use the Observable/Observer classes. Instead, one would create dedicated listeners and probably events for the model. In this case, this could be something like a TemperatureChangedListener and TemperatureChangedEvent. The Observable/Observer classes have been used here for brevity, because they are already part of the standard API.

Agin，请注意，可能有更复杂的应用案例，在这个小示例中勾画的 MVC 思想必须稍微扩展.特别是，当要执行的任务超出时，只需调用模型的方法.例如，当视图包含多个输入字段时，这些数据在传递给模型之前必须进行预处理或以其他方式验证.此类任务不应由匿名侦听器完成.相反，这些任务可以总结在一个类中，然后可以被称为控制器".然而，将实际的监听器附加到 GUI 组件仍然可以单独由视图完成.作为一个过于暗示的例子:这可能会像

Agin, note that there may be more complex application cases where the idea of MVC that is sketched in this small example has to be extended slightly. Particularly, when there are tasks to be performed that go beyond just calling methods of the model. For example, when the View contains several input fields, and this data has to be preprocessed or otherwise validated before it is passed to the model. Such tasks should not be done by an anonymous listener. Instead, such tasks could be summarized in a class that then may be called a "Controller". However, attaching the actual listeners to the GUI components can still be done solely by the View. As an overly suggestive example: This could then happen like

// In the view:
someButton.addActionListener(new ActionListener()
{
    @Override
    public void actionPerformed(ActionEvent e)
    {
        String s = someTextField.getText();
        Date d = someFormattedTextField.getDate();
        int i = someSlider.getValue();

        // The controller validates the given input, and
        // eventually calls some methods on the Model,
        // possibly using the given input values
        controller.process(s, i, d);
    }
});

这篇关于Java GUI App 控制器中的 ActionListener 是个好主意吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！