如果这两个帧的大小是相同的，为什么不创建一个帧，然后把它作为引用传递给它呢?

当你通过这个框架时，你可以决定如何填充它。这就像有了一种计算一组数字平均值的方法。你会一遍又一遍地创建这个方法吗?

The multiple JFrame approach has been something I've implemented since I began programming Swing apps. For the most part, I did it in the beginning because I didn't know any better. However, as I matured in my experience and knowledge as a developer and as began to read and absorb the opinions of so many more experienced Java devs online, I made an attempt to shift away from the multiple JFrame approach (both in current projects and future projects) only to be met with... get this... resistance from my clients! As I began implementing modal dialogs to control "child" windows and JInternalFrames for separate components, my clients began to complain! I was quite surprised, as I was doing what I thought was best-practice! But, as they say, "A happy wife is a happy life." Same goes for your clients. Of course, I am a contractor so my end-users have direct access to me, the developer, which is obviously not a common scenario.

因此，我将解释多JFrame方法的优点，并戳破其他人提出的一些缺点。

Ultimate flexibility in layout - By allowing separate JFrames, you give your end-user the ability to spread out and control what's on his/her screen. The concept feels "open" and non-constricting. You lose this when you go towards one big JFrame and a bunch of JInternalFrames. Works well for very modularized applications - In my case, most of my applications have 3 - 5 big "modules" that really have nothing to do with each other whatsoever. For instance, one module might be a sales dashboard and one might be an accounting dashboard. They don't talk to each other or anything. However, the executive might want to open both and them being separate frames on the taskbar makes his life easier. Makes it easy for end-users to reference outside material - Once, I had this situation: My app had a "data viewer," from which you could click "Add New" and it would open a data entry screen. Initially, both were JFrames. However, I wanted the data entry screen to be a JDialog whose parent was the data viewer. I made the change, and immediately I received a call from an end-user who relied heavily on the fact that he could minimize or close the viewer and keep the editor open while he referenced another part of the program (or a website, I don't remember). He's not on a multi-monitor, so he needed the entry dialog to be first and something else to be second, with the data viewer completely hidden. This was impossible with a JDialog and certainly would've been impossible with a JInternalFrame as well. I begrudgingly changed it back to being separate JFrames for his sanity, but it taught me an important lesson. Myth: Hard to code - This is not true in my experience. I don't see why it would be any easier to create a JInternalFrame than a JFrame. In fact, in my experience, JInternalFrames offer much less flexibility. I have developed a systematic way of handling the opening & closing of JFrames in my apps that really works well. I control the frame almost completely from within the frame's code itself; the creation of the new frame, SwingWorkers that control the retrieval of data on background threads and the GUI code on EDT, restoring/bringing to front the frame if the user tries to open it twice, etc. All you need to open my JFrames is call a public static method open() and the open method, combined with a windowClosing() event handles the rest (is the frame already open? is it not open, but loading? etc.) I made this approach a template so it's not difficult to implement for each frame. Myth/Unproven: Resource Heavy - I'd like to see some facts behind this speculative statement. Although, perhaps, you could say a JFrame needs more space than a JInternalFrame, even if you open up 100 JFrames, how many more resources would you really be consuming? If your concern is memory leaks because of resources: calling dispose() frees all resources used by the frame for garbage collection (and, again I say, a JInternalFrame should invoke exactly the same concern).

我写了很多，我觉得我还能写更多。不管怎样，我希望我不会因为这是一个不受欢迎的观点而被否决。这个问题显然很有价值，我希望我提供了一个有价值的答案，即使它不是普遍的观点。

多帧/每帧一个文档(SDI) vs单帧/每帧多个文档(MDI)的一个很好的例子是Microsoft Excel。MDI的一些好处:

it is possible to have a few windows in non rectangular shape - so they don't hide desktop or other window from another process (e.g. web browser) it is possible to open a window from another process over one Excel window while writing in second Excel window - with MDI, trying to write in one of internal windows will give focus to the entire Excel window, hence hiding window from another process it is possible to have different documents on different screens, which is especially useful when screens do not have the same resolution

SDI (single - document Interface，即每个窗口只能有一个文档):

MDI(多文档接口，即每个窗口可以有多个文档):

这不是一个好的实践，但即使你希望使用它，你也可以使用单例模式。我在我的大部分项目中都使用了单例模式，这很好。

我想用一个我刚刚涉及到的例子来反驳“不友好”的论点。

在我们的应用程序中，我们有一个主窗口，用户在其中运行不同的“程序”作为单独的选项卡。我们已经尽可能地将应用程序保持在这个单一窗口中。

他们运行的一个“程序”显示了系统生成的报告列表，用户可以单击每行上的图标弹出一个报告查看器对话框。这个查看器显示的内容相当于报告的A4页，所以用户喜欢这个窗口非常大，几乎填满了他们的屏幕。

几个月前，我们开始收到客户的请求，要求将这些报表查看器窗口变成非模态的，这样他们就可以同时打开多个报表。

有一段时间，我拒绝了这个要求，因为我认为这不是一个好的解决方案。然而，当我发现用户如何绕过我们系统的“缺陷”时，我的想法改变了。

他们打开一个查看器，使用“另存为”功能将报告保存为PDF文件到特定目录，使用Acrobat Reader打开PDF文件，然后他们会对下一个报告做同样的操作。他们将使用多个Acrobat reader运行他们想要查看的各种报告输出。

所以我妥协了，让观众变得无模态。这意味着每个查看器都有一个任务栏图标。

上周，当最新版本发布给他们时，他们压倒性的反应是他们喜欢它。这是我们最近对系统最受欢迎的改进之一。

所以你继续告诉你的用户，他们想要的东西是不好的，但最终它不会给你任何好处。

一些注意事项:

对于这些非模态窗口，使用JDialog似乎是最佳实践 使用使用新ModalityType而不是布尔模态参数的构造函数。这就是为这些对话框提供任务栏图标的原因。 对于非模态对话框，向构造函数传递一个空的父窗口，但定位它们相对于它们的“父”窗口。 Windows上的Java版本6有一个错误，这意味着你的主窗口可能会在你不告诉它的情况下变得“总是在顶部”。升级到版本7可以解决这个问题

这是一段时间以来，我最后一次接触摇摆，但一般是一个坏的做法，这样做。我想到的一些主要缺点是:

It's more expensive: you will have to allocate way more resources to draw a JFrame that other kind of window container, such as Dialog or JInternalFrame. Not user friendly: It is not easy to navigate into a bunch of JFrame stuck together, it will look like your application is a set of applications inconsistent and poorly design. It's easy to use JInternalFrame This is kind of retorical, now it's way easier and other people smarter ( or with more spare time) than us have already think through the Desktop and JInternalFrame pattern, so I would recommend to use it.

我认为使用多个jframe不是一个好主意。

相反，我们可以在同一个JFrame中使用多个JPanel。

我们还可以在这些jpanel之间切换。它给了我们在JFrame中显示更多东西的自由。

对于每个JPanel，我们可以设计不同的东西，所有这些JPanel都可以一次显示在单个JFrameone上。

要在这个jpanel之间切换，使用JMenuBar和JMenuItems为每个JPanelor 'JButtonfor每个jpanel '。

多于一个JFrame不是一个好的实践，但是如果我们想要多于一个JFrame也没有什么问题。

但是根据不同的需求更改一个JFrame比使用多个JFrame更好。