【问题标题】:Does this situation warrant using the singleton pattern?这种情况是否需要使用单例模式?
【发布时间】:2015-04-21 15:16:58
【问题描述】:

我正在创建一个迷你软件应用程序,如果您愿意,它会使用多个“菜单屏幕”。例如;主菜单屏幕、登录屏幕和应用程序支持的所有不同功能的屏幕。我目前正在使用以下类处理此问题:

public class ScreenUpdater {

    public static void updateScreen(JPanel screen, JFrame frame) {

        SwingUtilities.invokeLater(new Runnable() {

            @Override
            public void run() {
                frame.remove(frame.getContentPane().getComponent(0));
                frame.getContentPane().add(screen);
                frame.invalidate();
                frame.revalidate();
            }
        });

    }

}

静态方法 updateScreen() 采用以下参数:

  • 出现在 JFrame 中的新屏幕(例如 new LoginScreen(MainScreen mainScreenRef))(请注意,LoginScreen 引用主屏幕,因此它本身可以引用原始 JFrame)。
  • 新屏幕将出现在其中的 JFrame。

这对我来说效果很好,但是我注意到了一些我认为是问题的东西。例如,LoginScreen 将在按下按钮时调用另一个屏幕,所有这一切都将发生在按钮的调用方法中,这让我相信即使 LoginScreen 没有显示,它仍然存在并具有对它的活动引用。此外,在两次返回同一屏幕后,新实例将堆积起来,垃圾收集器无法处理以前的实例,因为它们在堆栈中较低。

为了解决这个问题,我相信单例设计模式可能有用。

我的问题是(按重要性排序):

  • 我对堆积这些实例的想法是否正确?
  • 如果是这样,这是使用单例模式的理想情况还是有更好的解决方案?
  • 这种方法本身是不是一种非常糟糕的方法?

提前非常感谢大家!

澄清 - 这就是我提到垃圾收集问题时的意思。假设我们有一个名为 LoginScreen() 的类和一个名为 login() 的方法。方法 login() 实例化 MainMenu() 类,以便它现在可以出现在 JFrame 中。然后从 MainMenu() 类调用的任何方法都会在原始 login() 方法完成之前调用。这就是让我相信垃圾收集器不会收集原始 LoginScreen() 的原因。

【问题讨论】:

    标签: java menu garbage-collection singleton heap-memory


    【解决方案1】:

    简短的回答是不,这听起来不像是使用单例的理由。

    您曾说过,即使没有显示这些屏幕,您也会害怕将实例保留在这些屏幕上:是什么让您相信这一点?如果您没有对它们的任何引用,那么它们将有资格进行垃圾收集。一旦方法退出,假设您没有对屏幕的任何其他引用,那么该对象将有资格进行垃圾回收。

    但是,无论如何,所有这些听起来都像是 CardLayout 的工作。

    如果您想了解更多信息,请发帖MCVE

    【讨论】:

    • 感谢您的回答。我在问题的末尾添加了更新。
    • @quantum285 我的回答成立。方法调用的顺序与某物是否有资格进行垃圾收集实际上没有任何关系。一旦方法退出,假设您没有任何其他引用,那么它将有资格进行垃圾回收。
    • 不是顺序,而是层次结构。
    • @quantum285 同样,它仍然没关系。
    猜你喜欢
    • 2011-07-06
    • 1970-01-01
    • 1970-01-01
    • 2015-12-08
    • 2017-01-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多