現在、プロジェクトでは、いくつかの VO (値オブジェクト) クラスが、Serializable インターフェイスを実装することによってシリアル化されています。このクラスには、getter と setter しかありません。コード内で writeObject を実行したり、オブジェクトの状態を保存したりする場所はありません。
私のVOをシリアライズ可能にする価値はありますか??
現在、プロジェクトでは、いくつかの VO (値オブジェクト) クラスが、Serializable インターフェイスを実装することによってシリアル化されています。このクラスには、getter と setter しかありません。コード内で writeObject を実行したり、オブジェクトの状態を保存したりする場所はありません。
私のVOをシリアライズ可能にする価値はありますか??
簡単なケースで議論しましょう:エンティティがいくつかの値オブジェクトをラップしていて、たとえば Hibernate フレームワークでエンティティを管理したいとします。
Hibernate にはシリアライズ可能なクラスが必要な場合があります:
クラスは Serializable を実装する必要があります。厳密に言えば、これは要件ではありません。ただし、実際には、通常、Hibernate オブジェクトをシリアライズ可能にして、(潜在的に) マルチプロセッサー クラスター内で移行したり、Web サーバーの再起動時に保存および復元したりできるようにする必要があります。
もちろん、デフォルトのシリアル化ではリフレクションを使用してオブジェクトの状態を保存および復元するため、正確な writeObject および readObject メソッドを指定する必要はありません。
実際、これらのメソッドは、シリアライゼーションをカスタマイズしたい場合に興味深いものです。たとえば、正確なデフォルト値でデシリアライズ中にフィールド (クライアント クラスに存在するが、サーバー クラスには存在しない) を初期化する場合などです。