【发布时间】：2012-03-27 18:58:00
【问题描述】：
我正在使用 Groovy 开发一款游戏，并且正在考虑广泛使用闭包来使架构更简洁。 例如，为了实现状态效果（例如中毒），Player 对象将有一个闭包列表来执行每个游戏回合。保存游戏时必须对这些进行序列化。
在需要序列化的对象中存储闭包通常是个好主意吗？或者我应该选择更传统的架构（例如，存储 StatusEffect 对象列表）？
【问题讨论】：
标签： serialization groovy closures
【发布时间】：2012-03-27 18:58:00
【问题描述】：
有一个闭包列表来执行每个游戏回合听起来是一个非常好的主意:-)
序列化闭包是完全可能的。从 Groovy 1.8.5 开始，由于 dehydrate 和 rehydrate 两种方法被添加到 Closures 中，它变得更加容易（这样owner、thisObject 和 delegate 可以在序列化之前被剥离）
但我对保存数据的原生 java 序列化有疑问。对于在系统之间发送短期数据，它可能很棒（但即使那样我也会看protocol buffers或thrift）
考虑一下如果您需要更新游戏会发生什么？如果poisoned 影响中存在错误，那么每个在其保存文件中使用错误中毒闭包保存的用户都会保留该错误，直到它消失。在多人游戏中，人们还可以操纵他们保存的游戏文件以赋予自己意想不到或不需要的权力（因为权力本身的功能将存储在文件中）。我可以看到操纵毒药效果，因此它会增加 HP 而不是移除它们可能是有益的 ;-)
简而言之，我想我的意思是我会写出一个字符表，其中包含影响用户、库存、分数等的事物的 ID，然后检查并应用闭包，因为文件是阅读。
【讨论】：
-
谢谢。我摆弄了 Java 反编译器以查看 Groovy 如何在内部实现闭包，现在看到序列化它们没有任何问题。它们只是使用 doCall 方法自动生成的类，并存储了对闭包中使用的所有外部变量的引用。唯一的问题是它们总是带有对
this的引用，即使它没有被使用，但正如你所说，从 1.8.5 开始有一个可用的解决方法