我的理解是我可以实现Serializable
接口以使我的对象可序列化。
但是当writeObject
是一个接口时,我不知道Serializable
方法在哪里实现,所以它不包含方法的实现,只是一个定义?
答案 0 :(得分:3)
正如您已经注意到的, Serializable 是一个标记接口,没有任何方法可以实现。实现Serializable只是注意到这个序列化符合使用ObjectOutputStream
处理的序列化。
您提到的方法需要在实现 Serializable 接口的类中实现,并且会自动获取。由于没有义务实施它们,因此它们不包含在界面中。
http://docs.oracle.com/javase/8/docs/platform/serialization/spec/serial-arch.html#a4539
答案 1 :(得分:1)
到目前为止发布的所有答案都是正确的,我希望补充一些额外的评论:
java.io.Serializable
已经是Java 1.1 API的一部分(在Java的第一个版本中),并且是一种简单方式,程序员可以将任何类标记为特殊行为。
根据OOP原则,应该通过常规界面来完成,这是您(以及我和任何其他程序员)所期望的。像这样:
public interface Serializable<E>
{
public E read(DataInput input) throws IOException;
public void write(DataOutput output) throws IOException;
}
但是,由于Java中有许多需要序列化的类,因此Java语言设计者希望通过某种自动执行序列化的机制来节省程序员的麻烦。但是如何?
通过抽象类?不。这会阻止任何自定义类具有自己的层次结构(因为在Java中只有单个继承)。
使java.lang.Object
可序列化?也不是这样,因为这会阻止程序员决定哪些类应该可序列化,哪些不应该。
最重要的是,有一个hughe问题:请注意,方法read
应该创建并从DataInput流返回类E的对象。抽象类无法创建其子类的实例而无需进一步的信息(抽象类不知道哪个是应用的子类)。
因此,他们决定通过OOP并提供序列化作为序列化类ObjectOutputStream / ObjectInputStream的特殊非oop功能(以EJP的形式归功于此细节),形式为“虚拟“界面可识别的界面,代价是在某种程度上增加了对类定义的一些讨论,因为没有方法的界面是无意义(他们对java.lang.Cloneable
采用的方法相同)。
实际上,它会增加更多的烦恼,因为必须通过实施私有方法readObject
和writeObject
(由ObjectOutputStream指定)来完成自定义序列化,这是一个在Java接口方面不可描述的特性。
如今,这些标记可以通过注释来完成。好吧,把Serializable
想象成一个应该是注释的接口,但仍然是那些 - 无连接兼容原因的接口。