2012-04-07 25 views
2

状況:メインフォームは、特定のクラスのインスタンスを作成または変更するためのパラメータが入力されるテキストボックスを持つモーダルjDialogを呼び出します。disposeメソッドの呼び出し後にモーダルダイアログ変数にアクセスする

ダイアログが既存のインスタンスを変更する必要がある場合、ダイアログはパラメータとしてコンストラクタに渡されます。それ以外の場合、jDialogはClassAの新しいインスタンスを作成します。

問題:メインフォームはその新しいインスタンスにアクセスする必要があります。メインフォーム全体をパラメータとして渡し、メソッド呼び出しでダイアログに新しいインスタンスをプッシュさせるのは汚れたコードだと思います完全に再利用可能なスタンドアロンのダイアログは、新しいインスタンスを受け取るために特定のクラス名とメソッドを必要とする単一のメインフォームでのみ使用できます。

OKボタンをクリックした後、getClassAInstance()メソッド(既存のインスタンスが変更されているときにも呼び出すことができる)を呼び出すことによって、メインフォームがjdialogから新しいインスタンスを取得するようにすることははるかに論理的です。このメソッドは、問題のjdialogの新しいインスタンスに対して "setVisible(true)"メソッドの後に呼び出されます。ダイアログが現れます。メインフォームのスレッドは、モーダルであるためダイアログが閉じられるまでスリープします。 OKボタンはjDialogのdispose()メソッドを呼び出し、次に非常に次のステートメントはメインフォームによるjDialogのgetClassAInstance()呼び出しです。

はここ

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 

..質問のコードでも同じことだ:私はそれを試してみたし、完全に正常に動作するようです。しかし、それは良いコードですか? getClassAInstance()メソッドが "null"を返す危険はありますか?ガベージコレクタはjDialogが破棄された後、メインフォームがコールを完了する前にClassAインスタンスを収集したためですか?

私が自分自身を明確にしなかった場合、私は英語のネイティブスピーカーではありません。むしろいくつかのコードが表示される場合は、私に教えてください...

+0

あなたの英語はうまく構成されており、あなたの質問はうまく構築されています。 –

答えて

2

私はClassAインスタンスを保持するダイアログインスタンスのメンバ変数にアクセスするのは完全に合理的だと思うので、ダイアログインスタンスは、disposeを呼び出しただけでなく、範囲外になるまでガベージコレクションされません。

私はあなたが

someThingHappened(にClassA toThisObject)の署名を持つイベントハンドラ・インタフェースを定義した溶液にわずかな好みを与えるだろう、あなたのMainFormかにClassAの事はそのインターフェイスのメイクを実装することを興味があるかもしれない何かを作りますダイアログを表示する前にダイアログにリスナーを追加することは可能です。

このようにして、ダイアログとメインフォームの結合を少し緩めます。

+0

確かに、OKボタンをクリックする以外の方法でダイアログが破棄された場合にコードをクリーンアップすることもできます。この場合、getClassAInstance()メソッドは、作成が必要な場合は常にnullを返します。新しいClassAインスタンス – MarioDS

+0

+1 'firePropertyChange()'から 'Observable'デリゲートを追加することができます。 – trashgod

1

dispose()はガベージコレクションのJDialogを設定するのではなく、リソースを解放すると思います。ダイアログには、まだ(JDialogのはウィンドウからこのメソッドを継承するため)Window APIあたりとして再利用可能である:

このWindowが使用するネイティブスクリーンリソースをすべて解放し、そのサブコンポーネント、その所有されたすべての子。つまり、これらのコンポーネントのリソースは破棄され、消費するメモリはすべてOSに返され、表示不可能とマークされます。

次のpackまたはshowの呼び出しでネイティブリソースを再構築することで、ウィンドウとそのサブコンポーネントを再び表示可能にすることができます。再作成されたウィンドウとそのサブコンポーネントの状態は、ウィンドウが配置された時点でのオブジェクトの状態と同じになります(これらのアクション間の追加の変更は考慮されません)。

注:Java仮想マシン(VM)内の最後の表示可能なウィンドウが廃棄されると、VMが終了することがあります。詳細については、「AWT Threading Issues」を参照してください。

限り、まだ存在JDialogのオブジェクトへの有効な到達参照があるとして、それはゴミが収集されることはありません。ダイアログを破棄するコストは、リソースを再作成するために少しでも時間を費やす必要があるということです。

+0

あなたの明確な答えをありがとう。私は投票しますが、まだ十分な評判はありません:) – MarioDS

+0

@MarioDeSchaepmeester:あなたは大歓迎です、そして、StackOverflow.comへようこそ! –

1

Disposeが呼び出されてからDisposeが呼び出される前に起こったことに関する情報を返すために呼び出された後に使用されるプロパティまたはメソッドを含むことは、全く妥当であり適切です。配置されたオブジェクトのすべてのメソッドがObjectDisposedExceptionをスローするルールを盲目的に強制するのではなく、代わりに配置されたオブジェクトに対してどのメソッドとプロパティが意味を成すかどうかを検討する必要があります。廃棄されたオブジェクトにアクセスしようとすると、解放されたリソースを再取得すること、または処分の結果として発生するその他の例外をエスケープすることより優先的に を投げてください。解放されたリソースがなくてもメソッドまたはプロパティへのアクセスが成功する場合は、そのアクセスを許可する必要があります。

関連する問題