私は、リスナーが登録されたシリアル化可能なオブジェクトを持っています。現在、リスナーのリストはオブジェクトにとして格納されています。オブジェクトがシリアライズされてデシリアライズされると、明らかにリスナーは登録されなくなります。リスナーを失うことなくオブジェクトをシリアライズおよびデシリアライズする最良の方法は？
オブジェクトが逆シリアル化された後にリスナーを自動的に再登録する最も安全な方法は何ですか？ここで助けになる良いデザインパターンがありますか？
イベントのリスナーとブロードキャストの両方として機能し、実際のリスナーを割り当ててから、それをシリアル化対象のオブジェクトのリスナーとして割り当てるプロキシオブジェクトを使用できます。それをシリアル化してデシリアライズすると、デシリアライズされたオブジェクトのリスナーとして再割り当てするだけです。
デカップリングされたイベントフレームワークを構築します。つまり、イベントプロデューサはイベントコンシューマに直接バインドされません。 これは、EventManager、EventProducer、およびパブリッシュ/サブスクライブのセマンティクスとともに動作するEventListenerで構成できます。
public interface EventManager {
public void postEvent(Event event);
public void addListener(Class eventType, EventListener listener);
}
public interface EventListener {
public void handleEvent(Event event);
}
に発行しています。オブジェクトが直列化解除されると、EventManagerにイベントをまだポストできます。
一般に、私はこれに有用なパターンを認識しませんでした。しかし、いくつかの組み合わせはOKです:)。問題は、デシリアライゼーションの処理方法です。標準的な方法を使用している場合は、ローカルリスナーの位置を突き止めて直し直したインスタンスにバインドするためのルックアップメカニズムを導入することができます。独自のデシリアライザを使用している場合、方法はよりシンプルになります。オブジェクトをデシリアライズしてローカルリスナーを登録するだけです。デシリアライザは、可能であればプロキシリスナとして動作できます。 Panagiotis氏によると、いくつかの分離モデルを導入することも役立つはずです。正確な解決策は実際のニーズに依存しますが、KISSを忘れないでください。
パブリッシャーとサブスクライバーの両方が登録するレジストリーを使用してください。 Korros氏が投稿したように、OSGIの土地ではWhiteboard Patternと呼ばれています。
readObject（）を実装すると、デシリアライズの一部として一時状態を再構成できます。 deserializationはオブジェクトの構築として扱う必要があります（そのためです）。
private void readObject(ObjectInputStream in)
throws ClassNotFoundException, IOException {
// do normal serialization first!
in.defaultReadObject();
// put code here that can somehow reconstruct your listeners
// presumably you have someplace you can look them up
}
これは、あなたには、いくつかの詳細を与えたいと思うかもしれません...少し曖昧ですが...それは、シリアライズされている状況は何ですか/デシリアライズされた... –
うわー..私はあなたがの多くを必要とするだろうと思います情報..オブジェクトが（仮定的に）アプリケーションの境界を越えて移動するようにシリアル化されている場合、参照は無効になりますか？ –