GWT-RPC 和不可变传输对象

发布于 2024-11-10 13:56:33 字数 452 浏览 5 评论 0原文

GWT-RPC 要求要序列化的传输对象必须具有默认值(零 -参数)构造函数。同样,最终字段不会被序列化(请参阅问题 1054< /a>)。

另一方面,我知道我应该“最小化可变性”。我的倾向是希望我的 TO 是不可变的,具有最终字段,没有默认构造函数,也没有修改器。

如何在使用 GWT-RPC 的同时尽可能尊重不可变范例。我是否必须转换为可变对象以进行编组,然后再转换回不可变对象?这值得吗?

GWT-RPC requires that transfer objects to be serialized must have a default (zero-argument) constructor. Similarly, final fields will not be serialized (see issue 1054).

On the other hand, I know I am supposed to "minimize mutability". My tendency is to want my TOs to be immutable, with final fields, no default constructor, and no mutators.

How can I use GWT-RPC while respecting the immutable paradigm as much as possible. Do I have to convert to a mutable object to marshall, and then back to an immutable one? Is this even worthwhile?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

情魔剑神 2024-11-17 13:56:33

Effective Java(第二版第15条)给出策略关于如何最小化可变性或支持不变性。

假设我们删除了修改器,但保留了非最终字段和默认构造函数。理论上,效果将是一个可变的对象,但实际上是一个不可变的对象。是的,人们可以通过反射来改变对象,但通过简单地关闭公开的方法,我们至少可以阻止在这种情况下改变它,在这种情况下,使对象真正不可变是不切实际的。

Item 13 in Effective Java (item 15 in second edition) gives strategies on how to minimize mutability or to favor immutability.

Suppose we remove mutators but retain non-final fields and a default constructor. The effect will be a theoretically mutable object, but a practically immutable one. Yes, one could mutate the object via reflection with a bit of effort, but by simply closing off the exposed methods we can at least discourage mutating it in cases like this where it's impractical to make the object truly immutable.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文