ファイル名で保存してロードしたい設定の束を扱うJPanelがあります。Javaオブジェクトはそれ自体をシリアル化できますか？
パネルにはすでに存在しており、ボタンに関連付けられたSave（Stringファイル名）およびLoad（String filename）アクションによって、パネル自体がロードと保存を処理する必要があることは自明です。
しかし、私が見つけたすべてのシリアライズおよび/または永続化の例では、オブジェクトをシリアライザ機能に渡す外部監督が必要です。
writeObject（this）とthis = readObject（）のようなものを使用してパネルオブジェクトをシリアライズするか、これを行うための標準的な方法がありますか？
私はこの質問を完全に理解していますが、すべてのシリアル化ロジックはObjectメソッド（readObjectとwriteObject）にあります。
誰がそれらのメソッドを呼び出すのかについて話をするとき、すべてがあなたのユースケースに依存します。例のようにオブジェクトをシリアライズする理由はいくつかあります。ワイヤを渡ってオブジェクトを別のJVMに渡したい場合や、JVMの再起動の間にオブジェクトの状態を保持したい場合や、状態全体オブジェクトのJVMの外部に保存する必要があります。
あなたのユースケースでは、それはできますか？はい。それは良い練習か、多分そうではないかもしれません。 JPanelにアクセスできない他のオブジェクトを永続化する必要がある場合には、抽象化が優れていますか？オブジェクトをシリアライズする前に他のロジックを実行する必要がある場合はどうなりますか？ JPanelで処理できない注文やその他の要件が必要な場合はどうなりますか？
Javaシリアル化の詳細については、here
これを閉じるには：私は初期のクイックダーティクラスのレイアウトをMVCの原則に基づいたものに変換しました。この質問を私にもたらした摩擦は消えました。 Javaチームのスコア1、@ Jochenにも感謝 –
です。しかし、あなたはしたいですか？ MVCパターンは理由があります。 – Jochen
私はこれがC++の推論だと自筆では認めていますが、アプリケーション設定がMVCスタイルの分割に適しているとは思えません。しかし、残りのアプリケーションの99％で私は完全に同意します。 –
興味深いですが、一度設定をロードするとどこに移動しますか？あなたがアプリに何らかの形でアクセスする必要がある場合、モデルクラスだけでなく、（相対的に）重量のあるJPanelを読み込むのはなぜですか？ – Jochen