要想使一个类的实例可被序列化,非常简单,只要在它的声明中假如“implemants Serializable”字样即可。正因为太容易了,所以普遍存在这样一种误解,认为程序猿可以毫不费力就可以实现序列化。实际情形要复杂得多。虽然使一个类可序列化的直接成本可以忽略不计,但长期的成本通常是很高的。
实现Serializable接口而付出的最大代价是,一旦一个类被发布,就大大降低了“改变这个类的实现”的灵活性 。当一个类实现了Serializable接口,它的字节流编码(或者说序列化形式(serialized form))就变成了它的导出的API的一部分。一旦这个类被广泛使用,往往必须永远支持这种序列化形式,就好像你必须要支持导出的API的所有其他部分一样。如果你不努力设计一种自定义的序列化形式(custom serialized form),而仅仅接受了默认的序列化形式,这种序列化形式将永远地束缚在该类最初的内部表示法上。换句话说,如果你接受了默认的序列化形式,这个类中私有的和包级私有的实例域都将变成导出的API的一部分,这不符合“最低限度地访问域”的实践准则(第15项),从而它就失去了作为信息隐藏工具的有效性。
如果你接受了默认的序列化形式,并且以后又要改变这个类的内部表示法,结果可能导致序列化形式的不兼容。客户端程序企图用这个类的旧版本来序列化一个类,然后用新版本进行反序列化(反之亦然),结果将导致程序失败。在改变内部表示法的同时仍然维持原来的序列化形式(使用 ObjectOutputStream.putFields和ObjectInputStream.readFields),这也是可能的