当我们在 java 中开发一个类时，是否应该使该类可序列化的决定通常很简单。如果该类表示一个可以通过 n/w 传输的模型对象，它应该是可序列化的。
这个推理正确吗？
如果是这样，一些原生 Java API 类可序列化而其他类不可序列化背后的逻辑是什么？
从这个实现 Serilizable 的本机类列表中，似乎有不止一个理由实现 Serilizable。
http://download.oracle.com/javase/6/docs/api/java/io/class-use/Serializable.html
任何澄清将不胜感激。
【问题讨论】：
标签： java serialization
如果类代表一个模型对象，可以跨 n/w，它应该是可序列化的。 这个推理正确吗？
这个推理有些正确。如果您正在创建一个兼容性很重要的公共 API，您可能希望使类可序列化，可能有一天需要序列化。但是，如果您正在创建私有应用程序，则应仅在需要时才使类可序列化。尝试避免实现Serializable 的一个原因（其中一个）是它引入了维护和保护新添加的可序列化类的“接口”的需要：它的字节码表示。
如果是这样，一些原生 Java API 类背后的逻辑是什么？ 可序列化而其他则不是？从这个本地类列表中 实现 Serilizable 的，看来不止一个 实现可序列化的原因。
Java API 中的许多类不实现Serializable 的主要原因之一是，由于接口和继承的性质，任何扩展实现Serializable 的类的类也必须实现Serializable .例如，如果java.lang.Object implemented Serializable，则需要将每个 java 类设计为可正确序列化。这会给任何类的设计带来很大的负担：突然之间，需要考虑安全性和字节码的有效性和兼容性。
【讨论】：
何时实现 Serializable 的决定应该不简单。
实现此接口会将您的类暴露给用于创建对象的语言外机制。为此目的，语言外意味着在 Java 语言中通常的构造函数机制之外。这实际上是一件坏事，这意味着您可能需要重新验证反序列化对象上的所有类不变量并强制执行实例控制（如果有这样的系统）。
它可以使您的课程容易被破坏并且容易受到安全黑客的攻击。它还可能危及封装/信息隐藏（如果没有经过深思熟虑，就会永远将您束缚在特定的实现上）。
实现 Serialzable 应该是一个深思熟虑的、有意识的选择......然后，并且只有这样，您应该只序列化对象的逻辑状态。所有其他字段都应标记为瞬态。
【讨论】：