Zugriff auf die modale Dialogvariable nach dem Aufruf der dispose-Methode

Question

Situation: Ein Hauptformular ruft einen modalen jDialog mit Textfeldern auf, in denen Parameter vom Benutzer zum Erstellen oder Ändern einer Instanz einer bestimmten Klasse ausgefüllt werden, nennen sie ClassA.

Wenn der Dialog eine vorhandene Instanz ändern muss, wird sie im Konstruktor als Parameter übergeben. Andernfalls erstellt der jDialog eine neue Instanz von ClassA.

Problem: das mainform muss auf diese neue Instanz zugreifen, und ich denke, es ist unreiner Code, das gesamte Hauptformular als Parameter zu übergeben und das Dialogfeld die neue Instanz durch einen Methodenaufruf dorthin zu schieben, weil auf diese Weise Ein perfekt wiederverwendbarer eigenständiger Dialog wird nur mit einem einzigen Hauptformular verwendbar, das einen bestimmten Klassennamen und eine Methode benötigt, um die neue Instanz zu erhalten.

Es ist viel logischer, das Hauptformular die neue Instanz aus dem jdialog nach dem Klicken auf die Schaltfläche OK abrufen, durch Aufrufen einer getClassAInstance() -Methode (die auch aufgerufen werden konnte, wenn eine vorhandene Instanz geändert wurde). Die Methode wird nach der Methode "setVisible (true)" für eine neue Instanz des betreffenden jdialogs aufgerufen. Der Dialog erscheint, der Thread des Hauptformulars wird schlafen, bis das Dialogfeld geschlossen wird (weil es modal ist). Die OK-Schaltfläche ruft die dispose() -Methode des jDialogs auf, dann ist die allererste Anweisung der getClassAInstance() -Aufruf auf dem jDialog vom mainform.

Hier ist die gleiche Sache in Code ..

ClassAInstanceMakerDialog imd = new ClassAInstanceMakerDialog(this, true); 
imd.setVisible(true); 
//imd.dispose(); after OK button click 
System.out.println(imd.getClassAInstance()); //return a new ClassA instance 

//output: whatever ClassA.toString() should return, works fine 

Frage: Ich habe es ausprobiert und es scheint völlig in Ordnung zu arbeiten. Aber, ist es ein guter Code? Besteht die Gefahr, dass die Methode getClassAInstance() "null" zurückgibt, weil der Garbage Collector die ClassA-Instanz gesammelt hat, nachdem der jDialog entfernt wurde und bevor das Hauptformular den Aufruf abschließen konnte?

Bitte entschuldigen Sie, wenn ich mich nicht klar gemacht habe, ich bin kein englischer Muttersprachler. Wenn Sie lieber etwas Code sehen möchten, lassen Sie es mich wissen ...

Answer 1

Ich denke, es ist völlig legal, auf die Membervariable Ihrer Dialoginstanz zuzugreifen, die die ClassA-Instanz enthält. Die Dialoginstanz wird nicht unbemerkt gesammelt, bis sie den Gültigkeitsbereich verlässt, nicht nur, weil Sie dispose aufgerufen haben.

Ich würde geben leichte Präferenz zu einer Lösung, wo Sie eine Event-Handler-Schnittstelle mit einer Signatur von

someThingHappened (KlasseA toThisObject), machen Sie Ihre Hauptform oder etwas definieren, die interessiert sein könnten, dass KlasseA Sache, die Schnittstelle make implementieren Es ist möglich, dem Dialog Listen hinzuzufügen, bevor er sichtbar gemacht wird.

Auf diese Weise würden Sie die Kopplung zwischen dem Dialog und der Hauptform etwas lockern.

Answer 2

Ich glaube nicht, dass dispose() den JDialog für Garbage Collection setzt, sondern stattdessen nur Ressourcen freigibt. Der Dialog ist noch wiederverwendbar gemäß der Window API (seit JDialog erbt diese Methode von Fenster):

Releases alle nativen Bildschirm Ressourcen durch dieses Fenster, dessen Subkomponenten verwendet, und alle seine Kinder im Besitz. Das bedeutet, dass die Ressourcen für diese Komponenten zerstört werden. Der von ihnen verbrauchte Speicher wird an das Betriebssystem zurückgegeben und als nicht wiedergabebereit markiert.

Das Fenster und seine Unterkomponenten können erneut angezeigt werden, indem die systemeigenen Ressourcen mit einem nachfolgenden Aufruf von packen oder anzeigen neu erstellt werden. Die Zustände des neu erstellten Fensters und seiner Unterkomponenten sind mit den Zuständen dieser Objekte an dem Punkt identisch, an dem das Fenster angeordnet wurde (ohne zusätzliche Änderungen zwischen diesen Aktionen zu berücksichtigen).

Hinweis: Wenn das letzte anzeigbare Fenster in der Java Virtual Machine (VM) gelöscht wird, wird die VM möglicherweise beendet. Weitere Informationen finden Sie unter AWT-Threading-Probleme.

Solange es gültige erreichbar Verweise auf das JDialog Objekt noch vorhanden ist, wird es nicht Müll gesammelt werden. Ich denke, dass die Kosten für die Bereitstellung des Dialogfelds darin bestehen, dass Ihr Code ein (sehr) wenig Zeit aufwenden muss, um die Ressourcen neu zu erstellen.

Answer 3

Es ist durchaus sinnvoll und angemessen, haben eine IDisposable umfassen Eigenschaften oder Methoden, die nach Dispose verwendet werden können, genannt wird, um Informationen über die Dinge zurück, die passiert ist, bevor Dispose genannt wurde. Statt eine Regel blind durchzusetzen, die alle und alle Methoden eines entsorgten Objekts eine ObjectDisposedException werfen sollten, sollte man stattdessen überlegen, welche Methoden und Eigenschaften Sinn machen oder nicht, die auf entsorgten Objekten liegen. Der Versuch, auf ein entsorgtes Objekt zuzugreifen, sollte ObjectDisposedException bevorzugen, anstatt freigegebene Ressourcen erneut zu erwerben oder eine andere Ausnahme zu umgehen, die als Folge der Verfügung auftritt. Wenn die Methode oder der Eigenschaftenzugriff ohne die freigegebenen Ressourcen erfolgreich ausgeführt werden kann, sollte dies häufig erlaubt sein.