《Effective Java读书笔记》--序列化

谨慎地实现Serializable

实现Serializable有如下几点风险

• 实现Serializable的类一旦发布，则“改变这个类的实现”的灵活性将大大下降。
• 增长了错误和安全漏洞的可能性。
• 测试负担会增长。

为了继承而设计的类应该不多实现Serializable，接口也应该不多会扩展它。

保护性地编写readObject方法

不严格的说，readObject是一个“用字节流做为惟一参数”的构造函数"。因此在写readObject时，就想象本身正在编写一个构造函数。

例如，在一个类的构造函数中，对参数的有效性作了检查，而且也作了保护性拷贝的话，readObject中也应该实现该逻辑。Period类（参考 http://my.oschina.net/u/1453800/blog/263037#OSC_h3_2）的readObject能够写成这样：

private void readObject(ObjectInputStream s) throws IOException,
			ClassNotFoundException {
		s.defaultReadObject();
		start = new Date(start.getTime());
		end = new Date(end.getTime());

		if (start.compareTo(end) > 0) {
			throw new InvalidObjectException(start + "after" + end);
		}
	}

值得注意的是，这样实现后，start和end都不能再定义成final了。不过下文会介绍readResolve方法，能够做为保护性readObject的替代选择，而且保证start和end还能继续定义成final。

在readObject中，不管是直接方式仍是间接方式，都不要调用类中可被改写的方法。

必要时提供一个readResolve方法

readResolve有两个用法：

•  用来实现singletor的序列化
• 做为保护性的readObject方法的一种保守替代选择，它的好处有：减小代码冗余，也不须要考虑太多细节；消除了“序列化对于使用final域的人为限制”。

Peroid类的readResolve方法实现以下：

private Object readResolve() throws ObjectStreamException {
		return new Period(start, end);
}