私が初めて Java PreferencesAPI を使い始めたとき、API からの 1 つの明らかな省略はputObject()メソッドでした。なぜ彼らがそれを含めなかったのか、私はいつも疑問に思っていました。
そこで、グーグルで調べたところ、その方法を示す IBM の記事を見つけました: http://www.ibm.com/developerworks/library/j-prefapi/
彼らが使用している方法は、私には少しハックに思えます。なぜなら、行列にObject分割してbyte保存し、後で再構築する必要があるからです。
私の質問は、誰かがこのアプローチを試したことがありますか? オブジェクトを保存/取得するための良い方法であると証言できますか?.
また、Java 開発putObject()者が API を除外した理由にも興味があります。誰かが貴重な洞察を持っていますか?
また、Java 開発者が putObject() を API から除外した理由にも興味があります。誰かが貴重な洞察を持っていますか?
から: http://docs.oracle.com/javase/7/docs/technotes/guides/preferences/designfaq.html
この API に、任意のシリアライズ可能なオブジェクトを読み書きするメソッドが含まれていないのはなぜですか?
シリアル化されたオブジェクトはやや脆弱です。そのようなプロパティを読み取るプログラムのバージョンが、それを書き込んだバージョンと異なる場合、オブジェクトは適切に逆シリアル化されない (またはまったく逆シリアル化されない) 可能性があります。この API を使用してシリアライズされたオブジェクトを保存することは不可能ではありませんが、お勧めしませんし、便利なメソッドも提供していません。
この記事では、信頼できる方法について説明しています。別の方法がいくつかあることがわかります (たとえば、ピースの数とピース自体の数を保存して、それらを取得したときに簡単に把握できるようにするなど)。
シリアライゼーションに関するあなたのコメントは間違っています....保存したいオブジェクトはシリアライズ可能でなければなりません....それが、ドキュメントが使用する ObjectOutputStream がその仕事をする方法です。
はい、信頼できるメカニズムのように見えます。Serializable オブジェクトが必要です。putObject と getObject が API の一部ではない理由は、次の 2 つの理由からだと思います。
シリアル化されたオブジェクトをレジストリに保存すると、オブジェクトが非常に大きくなる可能性があるため、やや心配です。コンストラクターからオブジェクトを再構築する方法がなく、シリアル化されたバージョンが比較的小さい場合にのみ使用します。