java - 关于适配器模式应用于 Java 中 Swing 事件的一些说明

Question

我正在研究 Java Swing 以及如何使用适配器模式处理事件，而不是覆盖处理事件的所有方法。

我找到了这个简短的例子，我想知道我是否理解它:

import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JFrame;

public class Sketcher {
    JFrame window = new JFrame("Sketcher");

    public Sketcher() {
        window.setBounds(30, 30, 300, 300);
        window.addWindowListener(new WindowHandler());
        window.setVisible(true);
    }

    class WindowHandler extends WindowAdapter {
        public void windowClosing(WindowEvent e) {
            System.out.println("closing");
            window.dispose(); // Release the window resources
            System.exit(0); // End the application
        }
    }

    public static void main(String[] args) {
        new Sketcher();
    }
}

我所理解的是:

Sketcher 类包含一个简单创建新 Sketcher 实例的 main 方法。

Sketcher 实例创建一个新的 JFrame 对象，该对象仅在监视器上显示一个框架。

因此，当我创建新的 Sketcher 对象时，会创建一个新的 JFrame 对象。

在这里我有我的第一个疑问(这是一个普遍的 Java 疑问):

为什么我不在 Sketcher 类的构造函数中创建 JFrame windows 对象？

无论如何，在构造函数中，我为 JFrame 对象设置了一些属性，并向该 JFrame 添加了一个 WindowListener。

现在 addWindowListener 是一个新的 WindowHandler 对象，它是处理 Windows 事件的自定义对象。

现在我有两种可能性来处理这些事件:

1. 使用经典监听器:在本例中，我必须为 JFrame 上可能发生的所有可能事件实现特定监听器

2. 使用适配器(如本例所示)，因此在本例中，我使用一个名为 WindowHandler 的内部类，它扩展了 WindowAdapter< 类/强>。 WindowAdapter 类包含所有可能的 JFrame 事件的 void 方法。因此，在 WindowHandler 中，我只能定义我想要处理的方法，而不是所有方法。

我的推理对吗？这是一个很好的教程示例还是它提出了一些我现在看不到的问题？

Tnx

安德里亚

Answer 1

您的推理是正确的，但这里有一些注意事项:

1. 您问了这个问题为什么我不在 Sketcher 类的构造函数中创建 JFrame windows 对象？

   编译器正在为你做一些工作；它实际上将 JFrame 的初始化放在构造函数中。您还可以将 JFrame 初始化显式放置在构造函数中。

2. 您的 WindowHandler 类不必是内部类；它可以是任何实现 WindowListener 或扩展 WindowAdapter 的类。

3. AWT 和 Swing 中的 XXXAdapter 类只是提供相关接口(interface)的无操作便利实现的类的命名约定。它们并不是真正的适配器(见下文)。

4. 您的main实现必须位于您的框架类中；它可以在任何类中。

通常，我们不喜欢在构造函数内创建一堆东西，特别是如果可能有副作用的话。最好提供单独的构造和初始化方法。

特别是对于 Swing，通常会对组件进行子类化，以提供应用程序所需的 UI 特化，包括 JFrame。但保持业务逻辑分离。

尽管 swing 类名为 WindowAdapter，但它实际上并没有在 Adapter 模式的意义上进行任何调整。它提供的是 WindowListener 接口(interface)的所有方法的默认无操作实现，允许开发人员仅重写他/她感兴趣的方法。

所以我想说，这更多的是对重写的研究，而不是适应；后者通常用于make two incompatible APIs work together .