简体   繁体   English

这种情况是否需要使用单例模式?

[英]Does this situation warrant using the singleton pattern?

I am creating a mini software application and it uses multiple "menu screens" if you will. 我正在创建一个微型软件应用程序,如果您愿意,它将使用多个“菜单屏幕”。 For instance; 例如; a Main Menu Screen, a Login Screen, and a screen for all the different features the application supports. 主菜单屏幕,登录屏幕以及该应用程序支持的所有不同功能的屏幕。 I'm currently handling this using the following class: 我目前正在使用以下类处理此问题:

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

    }

}

The static method updateScreen() takes the following arguments: 静态方法updateScreen()采用以下参数:

  • The new screen to appear in the JFrame (eg new LoginScreen(MainScreen mainScreenRef)) (Note that the LoginScreen takes a reference to the main screen so it itself can reference the original JFrame). 出现在JFrame中的新屏幕(例如,新的LoginScreen(MainScreen mainScreenRef))(请注意,LoginScreen引用了主屏幕,因此它本身可以引用原始JFrame)。
  • The JFrame in which the new screen is to appear. 将在其中显示新屏幕的JFrame。

This is working well for me, however I have noticed something which I believe to be a problem. 这对我来说很好,但是我发现我认为有问题。 The LoginScreen for instance will call up another screen upon the press of a button, and all this will happen within the button's called method, leading me to believe that even when the LoginScreen is not being displayed, it still exists with active references to it. 例如,登录屏幕将在按下按钮时调用另一个屏幕,所有这些操作都将在按钮的调用方法内发生,使我相信即使未显示登录屏幕,该屏幕仍然存在并带有有效的引用。 Furthermore, upon returning to the same screen twice, new instances will pile up with the garbage collector not being able to dispose of previous instances as they are lower on the stack. 此外,在两次返回同一屏幕时,新实例将堆积起来,垃圾回收器将无法处理以前的实例,因为它们在堆栈中的位置较低。

To address this problem, I believe the Singleton design pattern could be of use. 为了解决这个问题,我相信可以使用Singleton设计模式。

My questions to you all are (in order of importance): 我对大家的问题是(按重要性排序):

  • Are my thoughts on the pile up of these instantiations correct? 我对这些实例化的想法是否正确?
  • If so, is this an ideal situation to use the Singleton pattern or is there a better solution? 如果是这样,这是使用Singleton模式的理想情况还是有更好的解决方案?
  • Is this approach in itself just an extremely poor one? 这种方法本身仅仅是一种极差的方法吗?

Thank you all very much in advance! 提前非常感谢大家!

CLARIFICATION - This is what I mean when I refer to the problem of garbage collection. 澄清 -当我提到垃圾回收问题时,这就是我的意思。 Say we have a class called LoginScreen() with a method called login(). 假设我们有一个名为LoginScreen()的类,并带有一个名为login()的方法。 The method login() instantiates the MainMenu() class so that this can now appear in the JFrame. 方法login()实例化MainMenu()类,以便现在可以将其显示在JFrame中。 Any methods that are then called from the MainMenu() class are called before the original login() method is completed. 在原始login()方法完成之前,将调用从MainMenu()类调用的所有方法。 This is what leads me to believe that the original LoginScreen() will not be collected by the garbage collector. 这就是让我相信垃圾收集器不会收集原始LoginScreen()的原因。

The short answer is that no, this doesn't sound like a reason to use a singleton. 简短的答案是不,这听起来不像是使用单例的理由。

You've said that you're afraid you're keeping around instances to these screens even when they aren't being displayed: what makes you believe that? 您曾经说过,即使没有显示这些实例,您也会担心它们会停留在这些屏幕上:是什么让您相信呢? If you don't have any references to them, then they'll be eligible for garbage collection. 如果您对它们没有任何引用,那么它们将有资格进行垃圾回收。 As soon as the method exits, assuming you don't have any other references to the screen, then the object will be eligible for garbage collection. 一旦方法退出,并假设您没有对屏幕的任何其他引用,则该对象将有资格进行垃圾回收。

However, all of this sounds like a job for CardLayout anyway. 但是,所有这些听起来还是CardLayout的工作。

If you want more info, please post an MCVE . 如果您需要更多信息,请发布MCVE

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM