Die Verwendung mehrerer JFrames: Gute oder schlechte Praxis? [geschlossen]

531

Ich entwickle eine Anwendung, die Bilder anzeigt und Töne aus einer Datenbank wiedergibt. Ich versuche zu entscheiden, ob ein separater JFrame zum Hinzufügen von Bildern zur Datenbank über die GUI verwendet werden soll oder nicht.

Ich frage mich nur, ob es empfehlenswert ist, mehrere JFrame-Fenster zu verwenden.

Hausierer
quelle
11
Nur wenn Sie auf ein Multi-Monitor-Setup abzielen!
DNA
17
Ich würde auch argumentieren, dass dies sprachunabhängig ist und mehr mit der Benutzeroberfläche als speziell mit Java zu tun hat .
wchargin
6
Ich würde dem zustimmen @WChargin Diese Frage ist wertvoller geworden, als ich jemals gedacht hätte!
Hausierer
1
Ich stelle fest, dass Anfänger (wie ich selbst) normalerweise mehrere JFrames verwenden. Wahrscheinlich, weil es einfacher ist, es aus dem Haupt-JFrame heraus aufzurufen, als beispielsweise ein CardLayout zu verwenden. Obwohl es in einigen Fällen nicht ratsam ist, es zu verwenden.
Hoodlum
Das Debuggen wäre wie das Essen von Kakteen. Dies ist nicht ratsam.
Taslim Oseni

Antworten:

447

Ich frage mich nur, ob es eine gute Praxis ist, mehrere JFrames zu verwenden.

Schlechte (schlechte, schlechte) Praxis.

  • Benutzer unfreundlich: Der Benutzer sieht mehrere Symbole in seiner Taskleiste, wenn er erwartet, nur eines zu sehen. Plus die Nebenwirkungen der Codierungsprobleme ..
  • Ein Albtraum zum Codieren und Verwalten:
    • Ein modaler Dialog bietet die einfache Möglichkeit, die Aufmerksamkeit auf den Inhalt dieses Dialogs zu lenken - wählen / korrigieren / abbrechen und dann fortfahren. Mehrere Frames nicht.
    • Ein Dialog (oder eine schwebende Symbolleiste) mit einem übergeordneten Element wird angezeigt, wenn auf das übergeordnete Element geklickt wird. Wenn dies das gewünschte Verhalten wäre, müssten Sie dies in Frames implementieren.

Es gibt verschiedene Möglichkeiten, viele Elemente in einer GUI anzuzeigen, z.

  • CardLayout(kurze Demo. ) Gut für:
    1. Assistentenähnliche Dialoge anzeigen.
    2. Anzeigen von Listen-, Baum- usw. Auswahlmöglichkeiten für Elemente, denen eine Komponente zugeordnet ist.
    3. Umschalten zwischen keiner Komponente und sichtbarer Komponente.
  • JInternalFrame/JDesktopPane Wird normalerweise für ein MDI verwendet .
  • JTabbedPane für Gruppen von Komponenten.
  • JSplitPane Eine Möglichkeit, zwei Komponenten anzuzeigen, deren Wichtigkeit zwischen der einen oder der anderen (der Größe) je nach dem, was der Benutzer tut, variiert.
  • JLayeredPane weit viele gut geschichtete Komponenten.
  • JToolBarEnthält normalerweise Gruppen von Aktionen oder Steuerelementen. Kann je nach Benutzeranforderung über die GUI gezogen oder ganz entfernt werden. Wie oben erwähnt, wird die Wiederherstellung entsprechend dem übergeordneten Element minimiert / wiederhergestellt.
  • Als Artikel in einem JList(einfaches Beispiel unten).
  • Als Knoten in a JTree.
  • Verschachtelte Layouts .

Wenn diese Strategien jedoch für einen bestimmten Anwendungsfall nicht funktionieren, versuchen Sie Folgendes. Richten Sie eine einzelne Hauptleitung ein JFrame, und dann werden JDialogoder JOptionPaneInstanzen für den Rest der frei schwebenden Elemente angezeigt, wobei der Rahmen als übergeordnetes Element für die Dialoge verwendet wird.

Viele Bilder

In diesem Fall, in dem die mehreren Elemente Bilder sind, ist es besser, stattdessen eines der folgenden Elemente zu verwenden:

  1. Eine einzelne JLabel(in einem Bildlaufbereich zentriert), um das Bild anzuzeigen, an dem der Benutzer gerade interessiert ist. Wie in gesehen ImageViewer.
  2. Eine einzelne Reihe JList. Wie in dieser Antwort zu sehen . Der Teil "einzelne Zeile" davon funktioniert nur, wenn alle die gleichen Abmessungen haben. Alternativ, wenn Sie bereit sind, die Bilder im laufenden Betrieb zu skalieren und alle das gleiche Seitenverhältnis haben (z. B. 4: 3 oder 16: 9).

Andrew Thompson
quelle
4
@ AndrewThompson Ich war noch nie auf eine Situation gestoßen, in der ich mehrere Sekunden brauchte, JFrameund habe diese Probleme nie in Betracht gezogen, danke für die Erklärung!
Jeffrey
4
@ user417896 " Kommt nur darauf an." Nein, tut es nicht. Ich habe Gimp benutzt. Es ist schrecklich und sollte ein MDI sein.
Andrew Thompson
4
@ryvantage "Sollte (Excel) MDI sein?" Gute Frage. Ich bin der Meinung, dass es dem Benutzer in beide Richtungen angeboten werden sollte (sicherlich nicht nur in MDI-Form). Zum Beispiel: 1) Ich verwende derzeit TextPad und durch Konfiguration nach meiner Wahl werden separate Instanzen geöffnet, die jeweils mehrere in einer Liste angezeigte Dokumente anbieten. 2) Obwohl ich FF normalerweise im Registerkartenmodus verwende, ziehe ich gelegentlich eine Registerkarte in ein neues Fenster. - Der gemeinsame Faktor in den Beispielen ist die Wahl des Benutzers. Liefern Sie die App. "Wie auch immer der Benutzer es will".
Andrew Thompson
12
@ AndrewThompson Sie haben gerade Ihr eigenes Argument mit Ihrem letzten Kommentar kontert. In Ihrer Hauptantwort sagen Sie, dass dies eine schlechte Praxis ist und niemals durchgeführt werden sollte, aber in Ihrem obigen Kommentar sagen Sie, dass Sie SDI manchmal mögen und wir unseren Benutzern die Wahl bieten sollten. Dies ist sicherlich genau das, was user417896 oben gesagt hat. Es hängt davon ab, ob. Dies ist einer meiner größten Hassmassen gegen meine Entwicklerkollegen. Die Tatsache, dass viele von ihnen religiös fanatisch gegenüber sogenannten „Best Practices“ werden. Wir hätten nicht die innovativen Benutzeroberflächen, die wir heute haben, wenn wir uns alle an „Best Practices“ halten und nicht außerhalb des Platzes denken würden.
DuncanKinnear
4
Riesige Verallgemeinerung! Es ist nicht IMMER schlecht, wenn der Benutzer seine Fenster einzeln steuert und über die Taskleiste einzeln darauf zugreift. Es empfiehlt sich, sich aller Optionen bewusst zu sein und diese intelligent auszuwählen. Es gibt sicherlich Fälle, in denen mehrere JFrames sehr sinnvoll sind.
Dawood ibn Kareem
203

Der Mehrfachansatz JFramewurde von mir implementiert, seit ich mit der Programmierung von Swing-Apps begonnen habe. Zum größten Teil habe ich es am Anfang gemacht, weil ich es nicht besser wusste. Jedoch , wie ich in meiner Erfahrung und Wissen als Entwickler gereift und begann zu lesen und zu absorbieren die Bewertungen des so viele erfahrenen Java - Online - Devs, machte ich einen Versuch, Abkehr von dem mehrfachen JFrameAnsatz (sowohl in aktuellen Projekten und zukünftigen Projekten ) nur um auf ... diesen ... Widerstand meiner Kunden zu stoßen! Als ich anfing, modale Dialoge zu implementieren, um "untergeordnete" Fenster und JInternalFrames für separate Komponenten zu steuern , begannen meine Kunden sich zu beschweren!Ich war ziemlich überrascht, als ich das tat, was ich für Best Practice hielt! Aber wie sie sagen: "Eine glückliche Frau ist ein glückliches Leben." Gleiches gilt für Ihre Kunden. Natürlich bin ich ein Auftragnehmer, sodass meine Endbenutzer direkten Zugriff auf mich, den Entwickler, haben, was offensichtlich kein alltägliches Szenario ist.

Also werde ich die Vorteile des Mehrfachansatzes erklären und JFrameeinige der Nachteile, die andere vorgestellt haben, mit Mythen zerstören.

  1. Ultimative Flexibilität im Layout - Indem Sie separate JFrames zulassen, geben Sie Ihrem Endbenutzer die Möglichkeit, die Anzeige auf seinem Bildschirm zu verteilen und zu steuern. Das Konzept fühlt sich "offen" und nicht einschränkend an. Sie verlieren dies, wenn Sie sich einem großen JFrameund einem Haufen JInternalFrames nähern .
  2. Funktioniert gut für sehr modularisierte Anwendungen - In meinem Fall haben die meisten meiner Anwendungen 3 - 5 große "Module", die wirklich überhaupt nichts miteinander zu tun haben. Beispielsweise kann ein Modul ein Verkaufs-Dashboard und eines ein Buchhaltungs-Dashboard sein. Sie reden nicht miteinander oder so. Die Führungskraft möchte jedoch möglicherweise beide öffnen, und sie sind separate Frames in der Taskleiste, was ihm das Leben erleichtert.
  3. Erleichtert Endbenutzern das Verweisen auf externes Material - Einmal hatte ich folgende Situation: Meine App hatte einen "Daten-Viewer", über den Sie auf "Neu hinzufügen" klicken konnten, und es wurde ein Dateneingabebildschirm geöffnet. Anfangs waren beide JFrames. Ich wollte jedoch, dass der Dateneingabebildschirm ein JDialogübergeordneter Datenbetrachter ist. Ich nahm die Änderung vor und erhielt sofort einen Anruf von einem Endbenutzer, der sich stark darauf verlassen konnte, dass er den Viewer minimieren oder schließen und den Editor offen halten konnte, während er auf einen anderen Teil des Programms (oder eine Website, die ich nicht verweise, verwies) Ich erinnere mich nicht). Er ist nicht auf einem Multi-Monitor, daher musste der Eingabedialog an erster Stelle stehen und etwas anderesZweitens, mit dem Daten-Viewer völlig versteckt. Dies war mit einem unmöglich JDialogund wäre mit einem sicherlich auch unmöglich gewesen JInternalFrame. Ich änderte es widerwillig wieder, um JFramesfür seine geistige Gesundheit getrennt zu sein, aber es brachte mir eine wichtige Lektion bei.
  4. Mythos: Schwer zu codieren - Dies trifft meiner Erfahrung nach nicht zu. Ich verstehe nicht, warum es einfacher wäre, ein JInternalFrameals ein zu erstellen JFrame. In der Tat JInternalFramesbieten meiner Erfahrung nach viel weniger Flexibilität. Ich habe eine systematische Methode zum Behandeln des Öffnens und Schließens von JFrames in meinen Apps entwickelt, die wirklich gut funktioniert. Ich steuere den Frame fast vollständig aus dem Code des Frames heraus. die Erstellung des neuen Frames, der SwingWorkerdas Abrufen von Daten in Hintergrundthreads und des GUI-Codes in EDT steuert, den Frame wiederherstellt / nach vorne bringt, wenn der Benutzer versucht, ihn zweimal zu öffnen usw. Alles, was Sie zum Öffnen meines Frames benötigen, JFrameist Rufen Sie eine öffentliche statische Methode open()und die offene Methode in Kombination mit a aufwindowClosing() event erledigt den Rest (ist der Frame bereits geöffnet? Ist er nicht geöffnet, sondern wird geladen? usw.) Ich habe diesen Ansatz zu einer Vorlage gemacht, damit es nicht schwierig ist, ihn für jeden Frame zu implementieren.
  5. Mythos / Unbewiesen: Resource Heavy - Ich würde gerne einige Fakten hinter dieser spekulativen Aussage sehen. Obwohl Sie vielleicht sagen könnten, dass a JFramemehr Platz benötigt als a JInternalFrame, selbst wenn Sie 100 JFrames öffnen , wie viel mehr Ressourcen würden Sie wirklich verbrauchen? Wenn Ihr Problem Speicherlecks aufgrund von Ressourcen sind: Durch das Aufrufen werden dispose()alle Ressourcen freigegeben, die vom Frame für die Speicherbereinigung verwendet werden (und ich sage erneut, a JInternalFramesollte genau dasselbe Problem hervorrufen).

Ich habe viel geschrieben und ich habe das Gefühl, ich könnte mehr schreiben. Wie auch immer, ich hoffe, ich werde nicht einfach deshalb herabgestimmt, weil es eine unpopuläre Meinung ist. Die Frage ist eindeutig wertvoll und ich hoffe, ich habe eine wertvolle Antwort gegeben, auch wenn dies nicht die allgemeine Meinung ist.

Ein gutes Beispiel für mehrere Frames / ein einzelnes Dokument pro Frame ( SDI ) im Vergleich zu einem einzelnen Frame / mehreren Dokumenten pro Frame ( MDI ) ist Microsoft Excel. Einige der MDI-Vorteile:

  • Es ist möglich, einige Fenster in nicht rechteckiger Form zu haben, damit sie den Desktop oder ein anderes Fenster nicht vor einem anderen Prozess (z. B. einem Webbrowser) verbergen.
  • Es ist möglich, ein Fenster aus einem anderen Prozess über ein Excel-Fenster zu öffnen, während Sie in das zweite Excel-Fenster schreiben. Wenn Sie mit MDI versuchen, in eines der internen Fenster zu schreiben, wird der Fokus auf das gesamte Excel-Fenster gelegt, wodurch das Fenster vor einem anderen Prozess ausgeblendet wird
  • Es ist möglich, unterschiedliche Dokumente auf unterschiedlichen Bildschirmen zu haben. Dies ist besonders nützlich, wenn Bildschirme nicht dieselbe Auflösung haben

SDI (Single-Document Interface, dh jedes Fenster kann nur ein einziges Dokument haben):

Geben Sie hier die Bildbeschreibung ein

MDI (Multiple-Document Interface, dh jedes Fenster kann mehrere Dokumente enthalten):

Geben Sie hier die Bildbeschreibung ein

Ryvantage
quelle
16
Gut durchdacht. Wenn Sie mehrere Module haben, die nichts miteinander zu tun haben, können Sie separate Anwendungen erstellen. Es gibt auch keine Einschränkung, dass Sie modale Dialoge verwenden müssen. Sie könnten modelllose Dialoge verwenden, um als zweiter "Rahmen" zu dienen.
Jeffrey
Sehr gute Antwort und detaillierte Antwort, obwohl ich @kleopatra in dieser Frage zustimmen muss. Ich hatte einmal eine Anwendung mit über hundert Bildschirmen, in der Benutzer Ausgabedaten von mehreren Bildschirmen / demselben Bildschirm mit unterschiedlichen Eingaben vergleichen wollten. Wir haben ein benutzerdefiniertes Fenstersystem gebaut, um dies zu ermöglichen. Benutzer fühlten sich einfach wohler damit, 2 JFrames nebeneinander zu haben;)
javatarz
Obwohl ich Ihre Argumentation verstehe, würde ich es immer noch vorziehen, alles in einem JFrameund einem großen Elternteil zu haben JTabbedPane. aber mit der Möglichkeit, ein zweites Fenster (oder noch mehr) zu öffnen, in dem das Layout unterschiedlich sein kann, und somit ein hybrides Verhalten zu bieten, bei dem SDI-Liebhaber glücklich sind und auch MDI-Liebhaber. In allen Fällen habe ich immer JInternalFrameein schreckliches Muster betrachtet, das Ihnen alle Unannehmlichkeiten beider Welten bietet. Die Flexibilität, die sie bieten, ist einfach nur zum Kotzen und sie verbrauchen viel wertvollen Platz auf dem Bildschirm für keine wirklichen Zwecke.
Guillaume Polet
Ich bin damit einverstanden, dass SDI manchmal angemessen ist (und Benutzer bevorzugen es oft). Es gibt noch einen weiteren Nachteil, für den ich bisher leider keine Problemumgehung gefunden habe: Jeder JFrameerhält ein eigenes Taskleistensymbol. Manchmal ist es genau das, was Sie wollen, aber manchmal nicht. In WinAPI ist dies einfach zu konfigurieren, in Swing scheint dies jedoch nicht möglich zu sein.
Suma
@suma in diesem Fall denke ich, ich würde mich für eine JDialogüber a entscheiden JFrame.
Ryvantage
51

Ich möchte dem Argument "nicht benutzerfreundlich" mit einem Beispiel begegnen, an dem ich gerade beteiligt war.

In unserer Anwendung haben wir ein Hauptfenster, in dem die Benutzer verschiedene "Programme" als separate Registerkarten ausführen. Wir haben so viel wie möglich versucht, unsere Anwendung in diesem einzigen Fenster zu belassen.

Eines der von ihnen ausgeführten Programme enthält eine Liste der vom System generierten Berichte. Der Benutzer kann in jeder Zeile auf ein Symbol klicken, um ein Dialogfeld zur Berichtsanzeige zu öffnen. Dieser Viewer zeigt das Äquivalent der A4-Seite (n) im Hoch- / Querformat des Berichts an, sodass die Benutzer dieses Fenster als ziemlich groß betrachten und fast ihre Bildschirme ausfüllen.

Vor einigen Monaten haben wir Anfragen von unseren Kunden erhalten, diese Berichts-Viewer-Fenster modelllos zu machen, damit mehrere Berichte gleichzeitig geöffnet sein können.

Einige Zeit habe ich mich dieser Bitte widersetzt, da ich dies nicht für eine gute Lösung hielt. Meine Meinung wurde jedoch geändert, als ich herausfand, wie die Benutzer diesen „Mangel“ unseres Systems umgehen konnten.

Sie öffneten einen Viewer und speicherten den Bericht mithilfe der Funktion "Speichern unter" als PDF in einem bestimmten Verzeichnis. Mit Acrobat Reader öffneten sie die PDF-Datei und machten dasselbe mit dem nächsten Bericht. Sie würden mehrere Acrobat Readers mit den verschiedenen Berichtsausgaben ausführen, die sie betrachten wollten.

Also gab ich nach und machte den Betrachter modelllos. Dies bedeutet, dass jeder Betrachter ein Taskleistensymbol hat.

Als ihnen letzte Woche die neueste Version veröffentlicht wurde, ist die überwältigende Antwort von ihnen, dass sie es lieben. Es war eine unserer beliebtesten jüngsten Verbesserungen des Systems.

Sie sagen Ihren Benutzern also, dass das, was sie wollen, schlecht ist, aber letztendlich wird es Ihnen keinen Gefallen tun.

EINIGE NOTIZEN:

  • Es scheint eine bewährte Methode zu sein, JDialogs für diese modelllosen Fenster zu verwenden
  • Verwenden Sie die Konstruktoren, die das neue ModalityTypeund nicht das boolesche modalArgument verwenden. Dies gibt diesen Dialogen das Taskleistensymbol.
  • Übergeben Sie für modelllose Dialoge dem Konstruktor ein übergeordnetes Element null, suchen Sie sie jedoch relativ zu ihrem übergeordneten Fenster.
  • Version 6 von Java unter Windows weist einen Fehler auf, der bedeutet, dass Ihr Hauptfenster "immer oben" sein kann, ohne dass Sie es mitteilen. Aktualisieren Sie auf Version 7, um dies zu beheben
DuncanKinnear
quelle
6
Dies ist auch genau meine Erfahrung. Wenn es eine Sache gibt, bei der ich mir sicher bin, ist es, dass Sie etwas falsch machen, wenn Leute versuchen, Ihre Benutzerfreundlichkeit zu umgehen, um das zu tun, was sie wirklich wollen. Funktionalität ist König.
Ryvantage
Eine Möglichkeit, dies zu umgehen, besteht darin, das Öffnen mehrerer JFrames zuzulassen, die alle dieselbe Funktionalität bieten. Standardmäßig wird jedoch alles in einem einzigen Fenster ausgeführt. Dadurch kann der Benutzer tatsächlich zwischen SDI und MDI wählen.
Guillaume Polet
Es tut uns leid? Können Sie Ihre Lösung bitte etwas besser erklären? Wie kann es ein einzelnes Fenster UND mehrere Fenster sein? Wir haben ein Hauptfenster, in dem die Hauptanwendung ausgeführt wird, aber manchmal müssen wir Dialoge öffnen, und manchmal müssen diese Dialoge (basierend auf den Benutzeranforderungen) modelllos sein. Regeln aufstellen, dass die Benutzeroberfläche so sein soll oder dass Sie nur ein großes Loch für sich selbst graben.
DuncanKinnear
1
@ GuillaumePolet Ich stimme Duncan zu, kannst du erklären, was du ein bisschen mehr meinst? Ich teile seine Verwirrung
Ungeheuer
Ich denke, er meint damit, dass der Benutzer mehrere Kopien der Anwendung (den 'JFrame') starten könnte, aber in jeder dieser Anwendungen befindet sich SDI. Unsere Client-Anwendung ist jedoch ein sehr dicker Client, daher wäre dies ein ressourcenhungriger Ansatz.
DuncanKinnear
20

Machen Sie einen jInternalFrame zum Hauptframe und machen Sie ihn unsichtbar. Dann können Sie es für weitere Ereignisse verwenden.

jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);
Virendra Singh Rathore
quelle
19

Es ist eine Weile her, seit ich das letzte Mal Swing berührt habe, aber im Allgemeinen ist es eine schlechte Praxis, dies zu tun. Einige der Hauptnachteile, die mir in den Sinn kommen:

  • Es ist teurer: Sie müssen viel mehr Ressourcen zuweisen, um einen JFrame als eine andere Art von Fenstercontainer wie Dialog oder JInternalFrame zu zeichnen.

  • Nicht benutzerfreundlich: Es ist nicht einfach, in eine Reihe von zusammengeklebten JFrames zu navigieren. Es sieht so aus, als ob Ihre Anwendung eine Reihe von Anwendungen ist, die inkonsistent und schlecht gestaltet sind.

  • Es ist einfach, JInternalFrame zu verwenden. Dies ist eine Art Retorical. Jetzt ist es viel einfacher und andere Leute sind schlauer (oder haben mehr Freizeit), als wir bereits über das Desktop- und JInternalFrame-Muster nachgedacht haben. Daher würde ich empfehlen, es zu verwenden.

Necronet
quelle
7
Haben Sie nicht den gleichen Effekt für den Benutzer, wenn Sie auch mehrere verwenden JInternalFrame? Persönlich bin ich mit der Verwendung von JInternalFrame's nicht einverstanden ! CardLayoutist ein wahrer Segen!
Branislav Lazic
4
Ich stimme @ brano88 zu. JInternalFramebietet in keinem der drei von Ihnen genannten Fälle Vorteile (1. Wo ist der Beweis, der JInternalFrameleichter ist als JFrame? 2. Ihr JInternalFrames könnte genauso überladen / chaotisch / zusammengeklebt sein wie ein Haufen von JFrames. 3. Wie ist es JInternalFrameeinfacher? Es ist das der gleiche genaue Code, außer dass einer in a JDesktopPaneund einer im natürlichen Bildschirmbereich enthalten ist. Sie klingen für mich gleich komplex.)
ryvantage
1
1. JFrame ist eine hochgewichtige Komponente im Vergleich zu JInternalFrame, einem Leichtgewicht. 2. Haben Sie jemals eine App gesehen, die Tonnen von Fenstern gleichzeitig enthält, um funktionsfähig zu sein? IDE, Browser, auch in Finanzanwendungen ist es ein Ziel, es im gleichen Umfang zu halten. 3. Ich habe festgestellt, dass JIF in der Vergangenheit sehr einfach zu bedienen ist und habe natürlich keine Beschwerde, wählen Sie die Komponente aus, die am besten zu einem Szenario passt
Necronet
4
1. Ich würde gerne einen Beweis dafür sehen. Beide sind Objekte, beide sind JComponents, beide haben fast identische Strukturen, außer dass eines auf a gerendert wird JDesktopund eines nicht. Nochmals, sorry, aber ich glaube, Sie spekulieren über das "Gewicht" von JFrame. 2. Meine Anwendungen verwenden SDI und meine Kunden sind sehr zufrieden. Sie sagten jedoch "eine Menge Fenster", was natürlich scheiße wäre. Aber mein Punkt ist: "Eine Tonne" JInternalFramewürde genauso schlecht saugen! Wenn Sie sagen, dass JIFs es Ihnen ermöglichen, ein schlampiger UI-Designer zu sein, dann ist das schrecklich. Ein überladenes Durcheinander ist ein überladenes Durcheinander, egal ob JF oder JIF.
Ryvantage
2
"Natürlich wählen Sie die Komponente, die am besten zu einem Szenario passt"
Necronet
10

Schlechte Praxis auf jeden Fall. Ein Grund dafür ist, dass es nicht sehr "benutzerfreundlich" ist, da jedes JFrameein neues Taskleistensymbol anzeigt. Wenn Sie mehrere JFrames steuern, werden Sie sich die Haare ausreißen.

Persönlich würde ich ONE JFramefür Ihre Art von Anwendung verwenden. Es liegt an Ihnen, wie Sie mehrere Dinge anzeigen können. Es gibt viele. Canvases, JInternalFrame, CardLayout, auch JPanels möglicherweise.

Mehrere JFrame-Objekte = Schmerzen, Probleme und Probleme.

Matt Dawsey
quelle
9
hmm ... nichts Neues im Vergleich zu der akzeptierten Antwort, Afaics?
Kleopatra
5
"Jeder JFrame zeigt ein neues Taskleistensymbol" - dies gilt nur unter Windows! Unter Mac OS X verfügt jede Anwendung nur über ein Dock-Symbol, unabhängig davon, wie viele Fenster geöffnet sind. Anwendungen verfügen häufig über mehrere Fenster der obersten Ebene.
Rolf
8

Ich denke, mehrere Jframes zu verwenden ist keine gute Idee.

Stattdessen können wir JPanels mehr als ein oder mehrere JPanelgleichzeitig verwenden JFrame.

Auch können wir zwischen diesen JPanels wechseln . Es gibt uns also die Freiheit, mehr als nur etwas in der zu zeigen JFrame.

Für jedes können JPanelwir verschiedene Dinge entwerfen und all dies JPanelkann einzeln angezeigt JFramewerden.

Zwischen diesen wechseln JPanels Verwendung JMenuBarmit JMenuItemsfür jeden JPaneloder ‚JButton for eachJPanel`.

Mehr als eine JFrameist keine gute Praxis, aber es ist nichts falsch, wenn wir mehr als eine wollen JFrame.

Aber es ist besser, eine JFramefür unsere unterschiedlichen Bedürfnisse zu ändern, als mehrere zu haben JFrame.

Lijo
quelle
5

Wenn die Frames dieselbe Größe haben sollen, erstellen Sie den Frame und übergeben Sie ihn stattdessen als Referenz.

Wenn Sie den Frame übergeben haben, können Sie entscheiden, wie er gefüllt werden soll. Es wäre, als hätte man eine Methode zur Berechnung des Durchschnitts einer Reihe von Zahlen. Würden Sie die Methode immer und immer wieder erstellen?

Keith Spriggs
quelle
1
Das ist im Grunde das, was Cardlayout und JTabbedPane können, aber umgekehrt, und Ihr Code wird zu komplex, während Sie eine saubere und einfache Lösung haben, um dasselbe zu erreichen.
Guillaume Polet
4

Es ist keine gute Praxis, aber obwohl Sie es verwenden möchten, können Sie das Singleton-Muster als gut verwenden. Ich habe die Singleton-Muster in den meisten meiner Projekte verwendet, es ist gut.

Arunjoseph
quelle
3
Singleton-Muster ist ein Albtraum. Jedes Projekt, das skalieren möchte, sollte versuchen, das Singleton-Muster um jeden Preis zu vermeiden.
Guillaume Polet