3

この質問はかなり奇妙に聞こえるかもしれませんが、なぜjava.io.Serializableインターフェイスがクラスではなくインターフェイスとして正確に実装されているのでしょうか。

その点について考えさせられたのは、 /メソッドをオーバーライドすることについて話しているのに対し、定義上、それらをオーバーライドしないことです（つまり、これらのメソッドを既に実装しているオブジェクトのスーパータイプはありません）。readObjectwriteObjectSerializable

したがって、クラスである場合は、デフォルトの/メソッドSerializableを実装することができ、既存のクラスは、前述のメソッドを実際にオーバーライドすることができます。 readObjectwriteObject

これが私の言葉を説明する機能しない回避策です：

public class Serializable implements java.io.Serializable {

    private static final long serialVersionUID = 356223041512972356L;

    protected void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException {
        stream.defaultReadObject();
    }

    protected void writeObject(ObjectOutputStream stream) throws IOException {
        stream.defaultWriteObject();
    }

}

public class MyClass extends Serializable {

    private static final long serialVersionUID = -5437634103734137046L;

    @Override
    protected void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException {
        super.readObject(stream);
        // custom readObject method
    }

}

readObjectPS： /メソッドは私のものwriteObjectとして宣言する必要があるため、提供された回避策は機能しません。privateprotected

4

2 に答える 2

12

別のクラスから継承して実装したい場合は、本当に困惑するからですSerializable。これは、真の多重継承をサポートしないことを選択した場合に行われるJavaの一般的なトレードオフです。

Java 2.0言語（GroovyとScala）は、特性またはミックスインと呼ばれるものを介してその決定を覆したことに気付くでしょう。これらはほぼ正確にSerializable設計されているため、論理的に派生することなく機能を「ミックスイン」することができます。あなたが非常に良い点を指摘していて、Javaがあなたの意見に耳を傾けるのにうまくいったであろうという証拠として取るかもしれません。

于 2013-03-05T15:51:08.123 に答える
4

クラスだったとしたらjava.io.Serializable、別の基本クラスから継承することはできなかったでしょう。

別の言い方をすれば、それは継承かシリアル化のどちらかです。

于 2013-03-05T15:52:10.590 に答える