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

时间:2013-09-24 15:35:19

标签: java swing events adapter

我正在研究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();
    }
}

我所理解的是:

草绘器类包含一个简单创建新草绘器实例的主方法。

草绘器实例会创建一个新的 JFrame 对象,只显示监视器上的帧。

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

在这里,我首先怀疑(这是一个Java疑问):

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

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

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

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

  1. 使用经典监听器:在这种情况下,我必须为JFrame上可能发生的所有可能事件实现特定侦听器

  2. 使用适配器(就像在这种情况下一样),所以在这种情况下我使用一个名为 WindowHandler 的内部类来扩展类 WindowAdapter < / strong>即可。类 WindowAdapter 包含所有可能的JFrame事件的void方法。所以在 WindowHandler 中,我只能定义我想要处理的方法而不是所有方法。

  3. 这是我的推理吗?这是一个很好的教程示例,还是存在一些我现在看不到的问题?

    TNX

    安德烈

1 个答案:

答案 0 :(得分:1)

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

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

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

  2. 您的WindowHandler课程不 成为内部课程;它可以是任何实现WindowListener或扩展WindowAdapter的类。

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

  4. 您的main实现 不在您的框架类中;它可以在任何一个班级。

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

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

    即使swing类名为WindowAdapter,它实际上也不适应Adapter模式的意义。它提供的是WindowListener接口的所有方法的默认无操作实现,它允许开发人员仅覆盖他/她感兴趣的方法。

    所以我想说这更像是对overriding的研究而非适应;后者通常用于make two incompatible APIs work together