ActionListener在控制器中对于Java GUI App的好主意？ [英] Is ActionListener in controller for Java GUI App good idea?

问题描述

我不想跟随MVC模式。在互联网上，我看到最着名的例子是计算器，例如这里。我开始使用这种MVC模式的实现。但是现在我对控制器中的动作听众有一些疑问，因为他们倾向于观看。


主要原因是有很多更改链接到视图 - 字体，颜色，边框等。除了还有actionlisteners只修改视图！因此，在控制器中实现这样一个动作侦听器要困难得多（与简单的内部匿名类相比）。此外，它需要使控制器可以访问许多视图元素。


我有一个想法，在控制器和一些视图中保留一些动作侦听器，但会在将来导致混乱。所以我想听听别人的想法。

此问题与具有许多ActionListeners的MVC模式不重复

解决方案

MVC不是一个严格的模式。对原始模式有不同的解释，不同的衍生工具，如经常使用的MVP 或 MVVM （即使有人说他们正在使用MVC ）。

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

MVC模式出现的最常见问题是：什么是控制器？

答案：

升职的会计师

根据我的个人经验，很少有理由拥有一个显式Controller类。强制听众在一个控制器类中被累积和总结有几个严重的缺点。为了建立GUI组件和Model之间的连接，您有两个选择：一个选项是允许访问视图组件以附加监听器：

  gui.getSomeButton（）addActionListener方法（myActionListener）。 
  

我认为这是一个不用，因为它暴露了实现细节，阻碍了修改。另一个选择是更好 - 即提供允许附加监听器的方法：

  gui.addActionListenerToSomeButton（myActionListener）; 
  

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

在Swing应用程序中，我认为侦听器可以被认为是小控制者。而且我认为匿名听众直接调用模型的方法是完全可行的（除非有这些调用附加的逻辑）。说了这个：我不会把你链接的例子看作MVC的一个好的例子。首先，因为所选择的例子没有显示MVC的关键点：该模型不包含状态，而且MVC中的模型通常是必须观察到的东西（因此，作为附加的听众）并不清楚。其次，由于GUI和模型之间的连接建立方式是有问题的，因为上述要点。

我喜欢 http://csis.pace.edu/~bergin/mvc/mvcgui.html 。它的一部分可能会被质疑（例如，使用通用的Observer / Observable类），但我认为它以令人信服的方式很好地显示了MVC的基本思想。

---

编辑：没有以ZIP形式下载此示例。但您可以复制并粘贴 TemperatureModel ， TemperatureGUI ， FarenheitGUI 和 MVCTempConvert 进入IDE。 （它假定一个 CelsiusGUI 存在，这个 CelsiusGUI 在网站上被省略，但在结构上等同于Farenheit GUI。对于第一个测试，可以将其实例化的行注释掉）。

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

还有一些自由度。这不是一个完美或通用的MVC的例子。但是，与目前为止发现的其他大多数MVC的例子相比，IMHO比其他MVC更为出色，因为它很好地显示了重要的方面：

1. code>可观察


2. 视图是观察者


3. 控制器（即本例中的侦听器）是由视图维护的匿名/内部类，并调用模型的方法

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

Agin，请注意，可能会有更复杂的应用程序案例，在这个小例子中草拟的MVC的想法必须稍微扩展。特别是，当需要执行的任务超出，只需调用模型的方法即可。例如，当视图包含多个输入字段时，必须对该数据进行预处理或以其他方式验证，才能将其传递给模型。这样的任务应该不是由匿名侦听器完成。相反，这样的任务可以被归纳在一个类中，然后可以被称为控制器。但是，将实际的监听器附加到GUI组件仍然可以由View完成。作为一个过分暗示的例子：这可能会像

  //在视图中：
 someButton.addActionListener（new ActionListener（）
 {
 @Override 
 public void actionPerformed（ActionEvent e）
 {
 String s = someTextField.getText（）; 
日期d = someFormattedTextField.getDate（）; 
 int i = someSlider.getValue（）; 
 
 //控制器验证给定的输入，
 //最终在模型上调用一些方法，
 //可能使用给定的输入值
 controller.process（s，i，d）; 
} 
}）; 
  

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.

P.S. This question is not duplicate of MVC pattern with many ActionListeners

解决方案

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.

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

The answer:

"An accountant who got promoted"

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);

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.

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).

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.

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.

---

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).

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).

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. The Model is Observable
2. The View is an Observer
3. The "Controllers" (that is, the Listeners in this case) are anonymous/inner classes that are soleley maintained by the view, and call methods of the Model

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, 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);
    }
});

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