Java model 对象必须实现 Serializable 吗？

[sawyera]

前言

我实习生。

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

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

1. rpc 业务层面使用 fastjson 编解码 json String

2. mybatis 的操作与 Serialzable 接口无关

3. 业务层面前端入参和出参的 vo 也是 fastjson 编解码 json String

4. 查了资料复习此接口的使用，发现和我印象中的理解偏差不大

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

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

1. 有序列化的地方必须实现

2. 落库的对象必须实现

3. rpc 传输的对象必须实现

4. 老的代码都实现了 Serialzable 接口，没有人是不这么做的，别想偷懒

5. 老的项目中不实现 Serialzable 接口，然后踩坑了

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

后续

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

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

问题

1. Java model 对象必须实现 Serializable 吗？想知道大家都此接口的理解

2. 如果我的想法没错，那么同事对 Serializable 接口的理解是否反映某些问题？

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

[sagaxu]

祖传代码把 model 不加检查 cast 成 Serializable，抛异常了你去抓吗？

老项目就别作死了，宁可复制粘贴搞臭一点，也要保持队形

[lidlesseye11]

不用实现，以后真要用到了再加。这种东西行就是行，不行就是不行，哪有“可能下次调用就失败了”的情况。。。
但也不用纠结，说两句说不过乖乖加上就算了。。如果大家都加那至少看起来整齐（狗头

[kuangwinnie]

听领导的，他承担责任

[diegozhu]

同事属于保守派。
写代码自己不是老大的话，还是不要特立独行的好，跟群众走总是没错的。

现在测试能通过，只能代表当前这个代码，状态，结构能通过。保不准后面换个什么 orm，json 的框架，就尿崩了。
更保不准后面会引入什么框架需要。

要么你说服所有人，让他们都去掉或者你全部都去掉，要么你自己加，代码风格不一致以后会有很多坑。

[simonlu9]

Serializable 忘记加 uid 是个大坑，建议慎用

[hand515]

新项目能不用就不用

[shm7]

7 楼 18 楼 都是精明人

[monkeyWie]

可以不写但是没必要🐶

[passerbytiny]

一些（可能还是决大多数） RPC 框架，都需要 Serializable，如果不是独立项目，说必定哪天就可能要加 RPC，那时候规范化的 Serializable 可能会将成本降低 1 ％：Serializable 虽是鸡肋但不能弃。

维护现有规范，比制定新规范更容易。

以上两点决定了你的组长是对的。但是，以上两点决定了你的组长已经到上限了，你跟着他是没有前途的。

[zoharSoul]

让你写就写，别那么多废话，你吵了半天能给你加工资吗

犯不着纠结这种细枝末节.加就完事了.

[watcher]

大兄得,搞工程 没听过哪个砌墙抹灰的家伙敢放话说这面墙是多余的我不砌了...

[no1xsyzy]

寓言故事：猴子定律 或者 湿猴理论

顺便一提，作为没写过 Java 但成天听说 Java 反序列化出高危漏洞，觉得不实现比较安全。

[passerbytiny]

楼主和楼上的人有一些误区：

一、JSON 不是序列化。Java 对象与 Json 字符串之间不是一一对应而是多对一关系，JSON 只能做序列不能做反序列。加一些特殊标记可以将关系搞成一一对应，但那已经不是 JSON 了。Java 就算去掉现有的 Serializable，也是用二进制格式或者新建格式，新建格式可能会与 JSON 有关，但绝对不会是 JSON 。

二、虽然大多 RPC 用 JSON，但是基于 Java 序列化的 RPC 框架还活着并且活得不算差。

三、楼上有人已经提过了，Serializable 还没被标记为 Deprecated 。

[codingbody]

#### 五只猴子的故事

> 科学家在笼子里放了五只猴子。笼子中间有一架梯子，梯子上面放着香蕉。

每当一只猴子爬上梯子，科学家就用冷水泼洒其余的猴子。过了一阵子，只要一只猴子爬上梯子，其他猴子就会殴打它。一段时间后，所有猴子都不敢爬上梯子。

然后，科学家用一只新猴子，替换了原来的一只猴子，并且停止用冷水泼洒猴子。这只新猴子立即爬楼梯去拿香蕉，但随即遭到其他猴子的殴打。经过几次殴打，新猴子学会了不爬梯子，即使它从来不知道为什么。

接着，替换了第二只猴子，也发生了同样的事情。刚才放进笼子的那只猴子，同样殴打了新来的猴子。替换了第三只猴子，也是如此。就这样，第四只、第五只猴子也接连被替换了。

最终，笼子里面的五只猴子，尽管从未被泼冷水，仍然继续殴打任何试图爬上梯子的猴子。如果可以问猴子，为什么要殴打所有试图爬上梯子的成员，答案可能是：

"这就是我们在这里做事的方式。"

这个故事告诉我们，如果前人觉得某件事情不能做，阻力就会流传下来，阻止后来的人去做。

但是，大多数人没有意识到，有时候情况会改变。二十年前不可能的事情今天也许并非不可能。比如，电动汽车以前是不可能的，现在随着电池技术的进步，才有可能。

年轻人不知道为什么某事不能做，如果他们不怕阻力，就会去尝试那些不能做的事情。这就是为什么重大创新往往是年轻人做出来的原因。

老年人通常看不到新的机会，因为他们相信有些事情是不可能的。年轻人在无知和热情推动下，愿意尝试那些不可能的事情。大多数年轻人会失败，但少数会成功。


[阮一峰-科技爱好者周刊第 126 期]( http://www.ruanyifeng.com/blog/2020/09/weekly-issue-126.html)

[promisenev]

你是你们团队的 code 老大吗?
你能说服你们团队听你的吗?
你记住,你不是独立开发者,你是公司的打工仔,是和别人同步协作的,你觉得不加也行,然后同事说加,你就加上,就行了,团队代码规范统一点,怎么了?

[aguesuka]

@codingbody 通过调查，我们发现这个故事的出处还是比较清楚的。大多数网站都提到，它出自一本名叫《为未来竞争（ Competing for the Future ）》的商业书籍（谷歌图书已经有电子版[1]）。这本书的两位作者，一位是加里·哈梅尔（ Gary Hamel ），美国著名的管理学专家；另一位是普哈拉（ C. K. Prahalad ），密西根商学院的企业管理教授。他们在书里说，是从“一个朋友”处听来的实验。这个所谓的“实验”是否真实存在我们下文讨论。目前可以确定的是，将这个真实性存疑的“实验”写成通俗读本，引入大众文化圈的，正是这本商业管理领域的书籍。而最早将这个书本上的故事转载到互联网上是一家商业网站，他们则对这个故事有明确的定性，称它是一个“寓言”（ fable ）[2]。

或许是受限于 2000 年之前网络的不发达，早先这个故事流传得并不广泛。直到 21 世纪，伴随着互联网的蓬勃发展，这个故事出现的频率越来越高，尤其是近三年。在传播的过程中，“湿猴理论”慢慢地发生了变化：人们不再提到它是从哪来的，也忘记了它本是一个商业寓言，而是将其描述得越来越像是真实的科学实验。它的细节也在传播中逐渐变化：不同版本中，猴子的数量各有不同；实验的步骤发生了改变；用作负面刺激的冷水也被改成了电击。最令生物学家抓狂的是，故事的某个中文版本中甚至出现了详细的实验数据[3]！显然作者唯恐它不像真实的实验，不惜“杜撰数据”（话说这可是学术圈的大忌）。

在论述这个“实验”之后，各家都有对它的解读：有的教育人们不要扼杀新人的积极性；有的拿这些猴子作为模型讨论企业文化；还有的从中看到了人性的险恶。不过不管细节怎么改变，“实验”的流程、结果都与《为未来竞争》中那个寓言大致是一致的。

猴子，猴子！你湿过么？
既然故事本身只是个寓言，那么在真正的生物学和心理学研究中，有没有人做过类似实验呢？

拿猴子作为实验对象的科学研究确实不少。不过，流言中那样向猴子泼冷水不让它们吃香蕉的实验是真没有。这个“实验”从它的设计本身来说就是极不规范的。既没有对照组，也有没任何措施排除干扰因素。而且在香蕉面前，猴子真的会止步于冷水吗？德克萨斯大学的人类学教授布兰布利特（ Dr. Claud Bramblett ）与猴子们共处了 30 多年，他对这个故事是这样评价的：如果你把香蕉放在猴子够得着的地方，就别想再拿回你的香蕉（大意如此，原话见参考资料[2]

[aguesuka]

@codingbody 太假了以至于我忍不住搜了一下

[xiadada]

特地登陆回复你一下。 你们组其他人在这一点上都是彩笔。包括楼上不赞同的那几个观点。

另外最后你加上了，也没有做错，是我我也会加，我只一旦知道自己是正确的时候就会暂时的服从，随便你怎么说怎么改 反正我是对的。我以后也会越来越对，让他们错下去。

自己比别人好就行了。 持续努力 跳到更好的公司。

ps 当你去更好一点的公司的时候，大家可能说 你说的对，但是这个不好说（还是彩笔）

在你去更好的团队的（不是公司） 的时候 没有傻逼会在系统里遗留傻逼代码。

[siweipancc]

等一个用 redis 或者 mq 的后来者骂娘:D

[TransAM]

尽量避免用 java 自带的序列化和反序列化机制，json 就是个不错的选择。