2 
 class Parent implements Serializable{

      ........
 }

 class Child extends Parent{

      private void writeObject(ObjectOutputStream oos) throws IOException {
            throw new NotSerializableException();
      }
      private void readObject(ObjectOutputStream oos) throws IOException {
            throw new NotSerializableException();
      }

 }

上記のコードはSerializable、親が既に実装されている場合に子が回避する方法を示していますSerializable。それは悪い設計で、いくつかの点で混乱しているように見えるので、どのような状況でそれを行うことを検討しますか?

4

3 に答える 3

4

親がタグ付けされている場合、Serializableすべての子は設計上シリアライズ可能である必要があります。それ以外の場合、悪い設計の選択は、例外をスローしてシリアル化を禁止する方法ではなく、そうすべきではなかったという事実ですParentSerializable。

祖先クラスに実装されたインターフェイスを削除する方法がないため、選択の余地はありません。例外を発生させることは、シリアル化することを意図していないものをシリアル化するよりも常に優れています。これにより、何かがうまくいかなくなるまで、すべてがうまくいったと考えることができます。シリアル化されたデータで。シリアル化を禁止する理由は常にあります。シリアル化できないフィールドを子クラスに追加するだけで十分です (ただしtransient、フィールドに重要な情報が含まれている場合、これが常に可能であるとは限りません)。

于 2012-06-20T18:25:50.717 に答える
2

これが発生した理由として考えられるのは、親クラスがもともと親クラスとしてではなく、通常のシリアル化可能なクラスとして設計されていた可能性があることです。その後、誰かがシリアル化できない子クラスを作成しました。これは、親クラスに「設計上の欠陥」があることを意味するものではありません。

ではない特定の子クラスがある場合Serializable、唯一の欠点は、シリアル化が試行された場合に実行時例外が発生する可能性があることです。シリアル化できない子クラスがアプリケーションによってシリアル化されないことがわかっている場合、実際の問題はありません。

于 2012-06-20T18:36:13.510 に答える
0

Since Serializable is only a tagging interface, I don't see too much sense in the above construct. In Java there is no way to shadow this interface, which means that you are at the mercy of the code that is using your Child class. It may handle Serialization exceptions or may not.

One example when it handles such classes is when you've got some classes in a Java web container session, which gets persisted/restored to/from disk. In this case, Tomcat and other containers usually only give a warning but do not exit.

于 2012-06-20T18:29:59.217 に答える