Java model 对象必须实现 Serializable 吗？

前言

我实习生。

今天（ 2020-09-29 ），组长 review 我的代码时发现我 model 中的对象都没有实现 Serializable 接口，告诉我：”写得不对，所有有关落库、网络传输的对象都必须实现 Serializable 接口“。我不以为然，我印象中此接口是需要逐渐被废弃使用的，并且只有使用 Java 原生的序列化机制时才需要此接口。

我检查代码后还是觉得没必要实现 Serialzable 接口，原因：

rpc 业务层面使用 fastjson 编解码 json String
mybatis 的操作与 Serialzable 接口无关
业务层面前端入参和出参的 vo 也是 fastjson 编解码 json String
查了资料复习此接口的使用，发现和我印象中的理解偏差不大

以上，我认为此项目 model 中的对象不需要实现 Serializable 接口。

随后和组长、一些同事讨论了下，他们一致认为必须实现 Serialzable 接口，理由：

有序列化的地方必须实现
落库的对象必须实现
rpc 传输的对象必须实现
老的代码都实现了 Serialzable 接口，没有人是不这么做的，别想偷懒
老的项目中不实现 Serialzable 接口，然后踩坑了

我用我的原因进行反驳，同事的口径大致是：”如果我有能力承担不实现 Serialzable 接口带来的后果，那就不实现“。

后续

我老老实实地把 model 中的对象都加上了 Serialzable 接口。

后续怎么想怎么不对，我感觉自己的想法没错，我只是想把代码写得干净一点，想来问问大家对此接口的看法。

问题

Java model 对象必须实现 Serializable 吗？想知道大家都此接口的理解
如果我的想法没错，那么同事对 Serializable 接口的理解是否反映某些问题？

一些参考： https://v2ex.com/t/696834

312ybj

2020-10-02 08:29:15 +08:00

上次组长设计数据库，有很多字典表和冗余字段。但是这些是有道理的，后续系统扩展没这个东西就得重新设计一遍。我觉得代码是有生命周期的，完成功能不代表结束了，还得继续维护，后期可能追加功能。你刚实习，可能没有接触过频繁的需求修改。其实吧，面向变化的编码设计才能更好的应对变化的需求，你同事加了序列化就避免了序列化异常，下次需要用序列化的时候就不会报错。技术都是拿过来用的，业务才能体现价值

guyeu

2020-10-02 14:18:44 +08:00

@passerbytiny
1. 序列化(Serialization)是将对象的状态信息转换为可以存储或传输的形式的过程，反序列化是相反的过程。JSON 是一种可以存储或传输的数据格式规范，因此把对象转换成 JSON 的过程就是序列化，把 JSON 数据转换为对象的过程就是反序列化。这中间并不需要转出来的 JSON 和原来的对象一一对应，甚至不需要转出来的 JSON 能通过反序列化还原为原来的对象。不是很懂你对序列化有什么误解。
2. 能举一个活得还不算差的基于 Java 序列化的 RPC 框架吗，我觉得同时支持多种序列化方式的 RPC 框架可能不能算，因为有选择的情况下，多数人应该不会选它。。
3. 由于历史包袱，Java 中的确存在大量的不被推荐使用的 API，它们可能没有被显式标注废弃，但的确是在被逐渐减少使用，包括旧的 DateTime 相关工具类、clone 方法，也包括 Serializable 接口。

passerbytiny

2020-10-03 07:01:46 +08:00

@guyeu
1. 不可逆的序列化当然也是序列化，但要真把它当程序员用的序列化那特么的是想搞笑吗；如果不额外添加规则，把 Java 对象转换成 json 字符串是不可逆的。
2. Apache Storm 备用序列化，Hibernate 一些特别情况下的值对象，2.9 及之前的 Dubbo （新版本不知道是否有重构）；但“正在”不等于“已经”，“多说人不会去选择它”不等于“活得很差”；能够通用的序列化，也只有 JDK 的序列化，其它的都是框架自用标准（包括各种 Json 框架自带标
准），到底谁是多数那还说不准。
3. 如果你连 JDK 的标记都能有自己的解释，那就真得没啥可说了。

最后再说一句，请不要为了反驳而反驳——我的观点以及论述方式都在说得是 Serializable 有它存在的必要性而不是 Serializable 好。